Javadogs,

In chapter "15.3 Relationship Mapping" of the spec, "changes to the field mapped via mapped-by are not reflected in the datastore".

However, this conflicts with the text that follows:

 "... the column(s) will be changed during commit and will therefore be visible by both sides in the next transaction.".

I believe that the second part is more important than the first part. Specifically, if the user makes a change to a persistent field, at flush or commit time it makes sense to me that the implementation should make sure that the change is flushed to the datastore. Further, the spec says that changes will be visible by both sides in the next transaction, which has implications for RetainValues.

I think it's technically feasible for changes to either side to be reflected in the database, and for RetainValues to be handled consistently.

<proposed 15.3>
If two relationships (one on each side of an association) are mapped to the same column, the field on only one side of the association needs to be explicitly mapped.
The field on the other side of the relationship can be mapped simply by using the mapped-by attribute identifying the field on the side that defines the mapping. Regardless of which side changes the relationship, flush (whether done as part of commit or explicitly by the user) will modify the datastore to reflect the change. There is no further relationship implied by having both sides of the relationship map to the same database column(s). In particular, making a change to one side of the relationship does not imply any runtime behavior by the JDO implementation to change the other side of the relationship in memory prior to flush and will therefore be visible by both sides in the next transaction. If the RetainValues flag or DetachAllOnCommit is set to true, and the relationship field is loaded, then the implementation will change the field on the other side so it is visible after transaction completion.
Conflicting changes to relationships cause a JDOUserException to be thrown at flush time. Conflicting changes include: 
adding a related instance with a single-valued mapped-by relationship field to more than one one-to-many collection relationship
setting both sides of a one-to-one relationship such that they do not refer to each other
</proposed 15.3>


Craig Russell

Architect, Sun Java Enterprise System http://java.sun.com/products/jdo

408 276-5638 mailto:[EMAIL PROTECTED]

P.S. A good JDO? O, Gasp!


Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to