Ok, this is fixed. Actually looks like the fix may even have some
small positive impact on performance, as now less work is being done
when the object snapshot is taken.
Andrus
On Jul 8, 2006, at 12:55 PM, Andrus Adamchik wrote:
> 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 - 13:46:55 EDT