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
This archive was generated by hypermail 2.0.0 : Sat Jul 01 2006 - 16:54:36 EDT