db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig L Russell <Craig.Russ...@Sun.COM>
Subject Re: Setting a 1:1 association with "mapped-by"
Date Thu, 18 May 2006 03:07:40 GMT
This result is surprising, considering that we added verbiage to the  
specification to address this issue. I'll take a closer look, but my  
intent was not to allow this scenario, either in the datastore or in  
memory *after the transaction commits*.

The way the spec was changed near the end of the cycle, both sides of  
a relationship need to be consistent, both in the datastore and in  
memory after a flush operation.

This would be a candidate for a new TCK test to be released with a  
maintenance update of JDO.

The result you obtained should only be possible if both sides of the  
relationship were mapped to different columns in the datastore.


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  
The field on the other side of the relationship can be mapped by  
using the mapped-by at-
tribute 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 con-
sistency. 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 relation-
ship 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 RetainVal-
ues 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
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

On May 17, 2006, at 12:07 PM, Michael Bouschen wrote:

> Hi Jörg,
> you can create an unique index on the FK in the database. This  
> still does not automatically update the other side of the  
> relationship. But it prevents storing unexpected relationship  
> values into the database, because the transaction would fail if a2  
> still refers b2.
> The JDO implementation might support managing bidirectional  
> relationships in memory, but this is not mandated by the spec.
> Regards Michael
>> Eric Samson schrieb:
>>> /In particular, I'd expect a2 not pointing to b2 anymore, as this  
>>> clearly is supposed to be is a 1:1 relationship. The  
>>> implementation can determine this being a 1:1 association, as  
>>> there are two corresponding fields, and consequently it should  
>>> issue /
>>> Bu default, there is no 1:1 relationships either in Java or in  
>>> RDBMS.
>>> If you want to insure this 1:1 bi-directional link you have to:
>>>     * use some triggers in your db
>>>     * use a JDO callback
>>>     * do it cleanly in your set /getters in Java
>>>     * use an ORM tool that can manage 1:1 bi-directional links
>> I see. Hm. Well. For this relationship, being "bidirectional"  
>> seems to be equivalent to "being 1:1". Confusing.
>> Anyway, thanks for your answer!
>> Regards,
>> Jörg
> -- 
> Michael Bouschen		Tech@Spree Engineering GmbH
> mailto:mbo.tech@spree.de	http://www.tech.spree.de/
> Tel.:++49/30/235 520-33		Buelowstr. 66			
> Fax.:++49/30/2175 2012		D-10783 Berlin			

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!

View raw message