Hi Craig,

+1

Regards Michael

> 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:
> 
>
>
> 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!
>
>
> 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!
>
>


--
Michael Bouschen		Tech@Spree Engineering GmbH
mailto:mbo.tech@spree.de	http://www.tech.spree.de/
Tel.:++49/30/235 520-33		Buelowstr. 66
Fax.:++49/30/2175 2012		D-10783 Berlin

[ Post a follow-up to this message ]