db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From e...@jpox.org
Subject Re: Issue 150: Consistency requirements for relationships with mapped-by
Date Thu, 22 Dec 2005 13:41:52 GMT
I agree with the proposal

Quoting Craig L Russell <Craig.Russell@Sun.COM>:

> 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:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
>




Mime
View raw message