Re: more fault resolving oddness

From: Robert Zeigler (robert..uregumption.com)
Date: Sat Jul 08 2006 - 00:52:09 EDT

  • Next message: Borut Bolčin: "Re: oid as PK"

    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 - 00:52:36 EDT