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: Issue 150: Consistency requirements for relationships with mapped-by
Date Wed, 21 Dec 2005 19:23:05 GMT
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