| Bin Sun 2005-12-27, 5:45 pm |
| +1
--- Craig L Russell <Craig.Russell@Sun.COM> 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:
>
> one side and
> accordingly. But If I
> web-server), I can
> column referred by
> see different
> restarting), this
> have a consistency
> to hear why the
> restarts, but not
>
> 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!
>
>
__________________________________
Yahoo! for Good - Make a difference this year.
http://brand.yahoo.com/cybergivingweek2005/
|