db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig L Russell <Craig.Russ...@Sun.COM>
Subject Issue 150: Consistency requirements for relationships with mapped-by
Date Tue, 20 Dec 2005 22:04:37 GMT
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:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!


Mime
View raw message