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: Issue 150: Consistency requirements for relationships with mapped-by
Date Wed, 21 Dec 2005 02:22:40 GMT
Wow, that's definitely great! 
'Managed Bi-directional Relationship' feature is what
I have been waiting for so long, though this proposal
doesn't fully include MBR, it solved the problem in
most pratical cases.

--- Craig L Russell <Craig.Russell@Sun.COM> wrote:

> Javadogs,
> In chapter "15.3 Relationship Mapping" of the spec,
> "changes to the  
> field mapped via mapped-by are not reflected in the
> datastore".
> However, this conflicts with the text that follows:
>   "... the column(s) will be changed during commit
> and will therefore  
> be visible by both sides in the next transaction.".
> I believe that the second part is more important
> than the first part.  
> Specifically, if the user makes a change to a
> persistent field, at  
> flush or commit time it makes sense to me that the
> implementation  
> should make sure that the change is flushed to the
> datastore.  
> Further, the spec says that changes will be visible
> by both sides in  
> the next transaction, which has implications for
> RetainValues.
> I think it's technically feasible for changes to
> either side to be  
> reflected in the database, and for RetainValues to
> be handled  
> consistently.
> <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. There is  
> no further relationship 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
> will therefore be  
> visible by both sides in the next transaction. 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>
> 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!

Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 

View raw message