db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Bouschen <mbo.t...@spree.de>
Subject Re: [VOTE] Issue 150: Consistency requirements for relationships with mapped-by
Date Wed, 28 Dec 2005 22:22:32 GMT
Hi Craig,

+1

Regards Michael

> 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!
>
>


-- 
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			


Mime
View raw message