db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bin Sun <sun2...@yahoo.com>
Subject Re: [VOTE] Issue 150: Consistency requirements for relationships with mapped-by
Date Tue, 27 Dec 2005 01:27:01 GMT
+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:
> 
> > 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!
> 
> 
> 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/

Mime
View raw message