Wow, that's definitely great! 'Managed Bi-directional Relationship' feature is what I have been waiting for so long, though this proposal doesn't fully include MBR, it solved the problem in most pratical cases.
--- Craig L Russell <[EMAIL PROTECTED]> wrote: > 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! > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
