| 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:
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! |
smime.p7s
Description: S/MIME cryptographic signature
