Sweet! Many thanks!
Robert
Andrus Adamchik wrote:
> 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:53:15 EDT