cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrus Adamchik <and...@objectstyle.org>
Subject Re: more fault resolving oddness
Date Sat, 08 Jul 2006 16:55:10 GMT
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
>>
>
>


Mime
View raw message