So, I was testing the 7/7 nightly build to see how the fix for CAY-585
worked, and I've come across a new issue. I wondered if it was due to
the fix, :), so I've gone back and tested against nightly build 7/5 and
also 1.2RC2, and the problem still exists (so, not from the CAY-585 fix,
apparently). I wasn't sure whether to tag it onto the end of CAY-585 or
not. In any event, you can use the exact same mapping as in CAY-585 to
reproduce the error. Add the following line to the setUp method:
dc.performGenericQuery(new SQLTemplate(Assignment.class, "delete from
AssignmentTransaction"));
And then add the following test case:
public void testCayenneFaultCaseBaseObjectNewContext() {
DataContext dc = DataContext.createDataContext();
Assignment a = (Assignment)
DataObjectUtils.objectForPK(dc,Assignment.class,1);
AssignmentTransaction at = (AssignmentTransaction)
dc.createAndRegisterNewObject(AssignmentTransaction.class);
at.setAssignment(a);
dc.commitChanges();
dc = DataContext.createDataContext();
a = (Assignment) DataObjectUtils.objectForPK(dc,Assignment.class,1);
at = (AssignmentTransaction) a.getTransactions().get(0);
at.setStartTime(new Date());
at.getAssignment().getTitle();
}
This will produce a fault failure exception attempting to resolve the
object for: <Objectid:Assignmentid:1>.
I also played with the following test case, which produces no exception.
public void
testCayenneFaultCaseBaseObjectNewContextCleanTransactionFetch() {
DataContext dc = DataContext.createDataContext();
Assignment a = (Assignment)
DataObjectUtils.objectForPK(dc,Assignment.class,1);
AssignmentTransaction at = (AssignmentTransaction)
dc.createAndRegisterNewObject(AssignmentTransaction.class);
at.setAssignment(a);
dc.commitChanges();
int atpk = DataObjectUtils.intPKForObject(at);
dc = DataContext.createDataContext();
a = (Assignment) DataObjectUtils.objectForPK(dc,Assignment.class,1);
at = (AssignmentTransaction)
DataObjectUtils.objectForPK(dc,AssignmentTransaction.class,atpk);
at.setStartTime(new Date());
at.getAssignment().getTitle();
}
A few notes: The exception only occurs if you snag the transaction from
the re-fetched assignment (a.getTransactions()), and it only occurs if
you modify the transaction so fetched (at.setStartTime). Interestingly,
before the call to at.setStartTime(new Date()), at.getAssignment() works
fine, and a printout of the persistence state showed it as committed;
after the call to setStartTime, at.getAssignment().getPersistentState
shows it in state committed. This is not the case for the non-exception
producing test case.
Also, turning off the shared cache gets rid of the error. Also, it
does, in fact, matter that the AssignmentTransaction was already loaded,
but doesn't seem to matter exactly how it got loaded. For instance, the
following test case also produces an exception:
public void testCayenneFaultCaseBaseObjectNewContextPriorTransaction() {
DataContext dc = DataContext.createDataContext();
dc.performGenericQuery(new SQLTemplate(Assignment.class, "INSERT
into AssignmentTransaction (assignmentid,id) VALUES (1,1)"));
Assignment a = (Assignment)
DataObjectUtils.objectForPK(dc,Assignment.class,1);
AssignmentTransaction at;
a.getTransactions().size();//.size forces the assignment
transaction above to be faulted...
dc = DataContext.createDataContext();
a = (Assignment) DataObjectUtils.objectForPK(dc,Assignment.class,1);
at = (AssignmentTransaction) a.getTransactions().get(0);
at.setStartTime(new Date());
at.getAssignment().getTitle();
}
If you comment out the a.getTransactions().size() line, no exception
will be produced (and the at.setStartTime does /not/ cause the
assignment associated with at.getAssignment to wind up HOLLOW).
Robert
This archive was generated by hypermail 2.0.0 : Fri Jul 07 2006 - 21:42:21 EDT