You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@cayenne.apache.org by Robert Zeigler <ro...@puregumption.com> on 2006/07/01 22:54:10 UTC

fault exception

Ok... at long last, I've a few things to report on the exception
resolving fault issue I first mentioned back in May.
Here's the brief:
Tables:
Assignment
    id: pk
    transactions: toMany to AssignmentTransactions
    parameters: toOne to AssignmentParameters
    type: used for inheritance
    unimportant attributes
AssignmentTransaction:
    id: pk
    assignment: toOne to Assignment (uses assignmentid FK)
    unimportant attributes
AssignmentParameters:
    id: pk
    assignment: toOne to Assignment (uses assignmentid FK)
    unimportant attributes

Objects:
Assignment (type is NULL)
AssignmentTransaction
AssignmentParameters
Exam (extends Assignment; type is "exam").

In the test case, which I will attach to a JIRA issue I will open, I
fetch an Exam from the database, create a transaction, and set the
transaction's assignment to be the fetched exam.  Then I refetch the
Exam from the database and try to access the parameters of the Exam, and
get the fault exception.  Specifically, the AssignmentParameters can't
be resolved (note that they can be resolved before the refetch of the
assignment. Also note that it doesn't matter if I commit changes before
the refetch or not).  When looking at the queries involved, before the
refetch, the relationship resolving the fault attempts to execute an
objectidquery using this id:
object: AssignmentParameters; field: id; value: xxx. After the refetch,
the ObjectIDQuery used is: object: AssignmentParameters; field:
assignmentid; value: xxx.  In fact, the query does resolve an object.
But when the object is resolved, it ends up resolving with the correct
ObjectID (using the id field, not the assignmentid field) so when the
cache is updated, it updates using the correct key, rather than the
incorrect key, and so the object that was somehow accessed with the
incorrect objectid key isn't updated, and therefore remains hollow. 
This ONLY happens when I'm treating the Exam as an Assignment. That is,
if I do:
Assignment a = (Assignment)
DataObjectUtiils.objectForPK(dataContext,Assignment.class,xxx); where
xxx is the id of an exam. If I use the child class, there's no bug.
Again, I'll be opening a jira issue and attaching a test case and schema
that reproduces the exception.

Robert