I can confirm this bug. I am working on it now:
http://issues.apache.org/cayenne/browse/CAY-592
Thanks for doing all this testing!!
Andrus
On Jul 8, 2006, at 12:52 AM, Robert Zeigler wrote:
> I did a bit more research... as of 1.2M11, everything seems cheery. As
> of 1.2M12, I get the exceptions. HTH.
>
> Robert
>
> Robert Zeigler wrote:
>> 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 : Sat Jul 08 2006 - 12:55:35 EDT