Issue 150: Consistency requirements for relationships with mapped-by

[Craig L Russell <Cr...@Sun.COM>]

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!

Re: Issue 150: Consistency requirements for relationships with mapped-by

[Bin Sun <su...@yahoo.com>]

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 <Cr...@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 
http://mail.yahoo.com