+1 --- Craig L Russell <[EMAIL PROTECTED]> wrote:
> Javadogs, > > I'll hold this vote open until January 2. > > [ ] Adopt the proposal below. > > <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 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 and will > update the memory model for consistency. There is no > further behavior > 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 there is no requirement to load > fields affected > by the change if they are not already loaded. This > implies that 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> > > On Dec 21, 2005, at 11:23 AM, Craig L Russell wrote: > > Hi David, > > Thanks for your comments. > > The "in your face" issue I'm wrestling with is the > inconsistency in > the specification where we say that changes are > ignored if made to > the "mapped-by" side and also that changes made to > the memory model > are visible after commit. So I took a fresh look at > the requirements > and practical aspects of implementation. > > JDO 1.0 requires byte-code enhancement. JDO 2.0 now > admits > implementations that don't use byte-code > enhancement, weaving, or > aspects in order to intercept domain model changes > during a > transaction. Synchronizing the memory model with the > database is now > deferred to flush (which might happen during > commit). At flush time, > the JDO implementation gets control (possibly for > the first time > after loading the instances) and can do whatever the > spec requires. > It's evident to me that it's possible to detect > changes to either > side of the relationship and make the two sides > consistent. > > The proposal is carefully worded to not require that > the > implementation do extra work in case the memory > model is not fully > instantiated. In particular, it's possible to add a > hollow Employee > to a Department.emps collection without > instantiating the Employee > instance. Similarly, it's possible to set the > Employee.dept field to > a hollow Department without instantiating the > Department instance. > > The original wording in the JDO 2.0 spec was > informed by the work in > EJB3 which derived from TopLink and Hibernate > implementations that > don't worry much about the "mapped-by" side of the > relationship. But > I don't think that it makes sense for JDO that > users' model changes > to be ignored just because they happen to be made to > the "wrong side" > of the relationship. > > This proposal is where I ended up. > > 1. JDO implementations get control at flush; > 2. User changes should not be ignored; > 3. Inconsistencies should not be accepted, as they > indicate user code > gone bad. > > I agree it's a tradeoff. I'd like to see managed > relationships in > memory but given the constraints I don't see it > happening for JDO 2. > And I'd really like to see managed relationships be > a separate issue > addressed in another JSR. It's not just a > persistence issue; it's not > a mapping issue; it's a domain model issue. > > Regards, > > Craig > > Slightly updated for clarity: > > On Dec 21, 2005, at 3:52 AM, David Bullock wrote: > > > Bin Sun wrote: > > > >> Think that without managed relation, if I modify > one side and > >> commit, I can't see the other side changed > accordingly. But If I > >> restart the JDO engine (such as restarting the > web-server), I can > >> see the change then, since it uses the same > column referred by > >> 'mapped by'. So, without any JDO operation, we'll > see different > >> result at different time (before and after > restarting), this > >> becomes a real consistency > >> problem. > >> > > As the spec and the proposal stands, you still > have a consistency > > problem before and after commit. I'm interested > to hear why the > > consistency issue only matters between server > restarts, but not > > between before- and after- commit. > > > > cheers, > > David. > > 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! > > > 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! > > __________________________________ Yahoo! for Good - Make a difference this year. http://brand.yahoo.com/cybergivingweek2005/
