I agree with the proposal Quoting Craig L Russell <[EMAIL PROTECTED]>:
> 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: > > <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 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. 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 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! > >
