db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg von Frantzius <joerg.von.frantz...@artnology.com>
Subject Re: Bidirectional relationship tests in the TCK
Date Tue, 10 Jun 2008 12:30:33 GMT
Craig L Russell schrieb:
> Hi Jörg,
>
> On Jun 9, 2008, at 1:43 AM, Joerg von Frantzius wrote:
>
>> Hello Craig,
>>
>> what I really meant was: when modifying state of bidirectional 
>> associations on detached objects, should those detached objects 
>> immediately reflect consistent bidirectional state in the VM even 
>> before attaching? E.g. set a one-to-one association from one side, 
>> and immediately see the newly associated object from the other side.
>
> Well, no. Detached objects are not associated with a 
> PersistenceManager and so flush() or commit() cannot by definition be 
> applied to them. So there is no specified behavior that applies to 
> relationships of detached objects.
>>
>> "15.3 Relationship Mapping" says that "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 flush when modifying detached objects, so this doesn't 
>> really sound like the memory model should get updated before the 
>> detached objects are attached again and a flush actually happens. 
>> From an application programmer's point of view, it would of course be 
>> desirable if behaviour was consistent both in attached and detached 
>> state.
>
> It is consistent. If you flush or commit, all the specified behavior 
> occurs, regardless of where the changes were made (attached or detached).
That leads me to the question: why is the memory model to be updated 
only after flush()?

When I set an association and read it afterwards from the same side that 
I modified, I'll immediately see my changes without having to call 
flush() inbetween. So the behaviour for "seeing results of association 
modification" is depending on which side of the association I'm looking 
at. I wonder if that is really necessary? IMHO, it would be more 
consistent if an application programmer didn't have to think about which 
side of a bidirectional association (s)he is looking at.
>
> Once the detached object is brought into the domain of a 
> PersistenceManager via makePersistent, the flush and commit behavior 
> applies.
>
> Regards,
>
> Craig
>>
>>
>> Regards,
>> Jörg
>>
>> Craig L Russell schrieb:
>>> Hi Jörg,
>>>
>>> On Jun 6, 2008, at 10:30 AM, Joerg von Frantzius wrote:
>>>
>>>> Sorry for not having had any time to look into this more thoroughly 
>>>> yet. I'll hopefully find it next week.
>>>>
>>>> I think I experienced problems with changing bidirectional 
>>>> relationships on detached objects. Now I'm not sure whether the 
>>>> spec intended those to be managed as well?
>>>
>>> Sure, any change to a persistent field of a detached object should 
>>> be reflected in the database upon reconnection and commit.
>>>
>>> If you can write a test case, we'd be happy to consider adding it to 
>>> the TCK.
>>>
>>> Craig
>>>>
>>>>
>>>> Craig L Russell schrieb:
>>>>> HI Jörg,
>>>>>
>>>>> On May 27, 2008, at 9:51 AM, Joerg von Frantzius wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> when looking at the relationship tests in 
>>>>>> org.apache.jdo.tck.mapping, it seems that the tests for 
>>>>>> bidirectional integrity only test changing relationships from the

>>>>>> "mapped-by" side of the relationship? That's my impression at 
>>>>>> least from looking at the method names e.g. in 
>>>>>> Relationship1ToManyAllRelationships.java.
>>>>>
>>>>> There are a few relationship tests, and the intent was (is) to 
>>>>> test changing relationships from both sides.
>>>>>
>>>>> If you can't find what you're looking for (in all the tests) 
>>>>> please let us know.
>>>>>
>>>>> Craig
>>>>>>
>>>>>>
>>>>>> I'm asking this because I believe to see inconsistencies with 
>>>>>> bidirectional relationships in the RI.
>>>>>>
>>>>>> Regards,
>>>>>> Jörg
>>>>>>
>>>>>> -- 
>>>>>> ____________________________________________________________________
>>>>>> artnology GmbH - Milastraße 4 - 10437 Berlin - Germany
>>>>>> Geschäftsführer: Ekkehard Blome (CEO), Felix Kuschnick (CCO)
>>>>>> Registergericht: Amtsgericht Berlin Charlottenburg HRB 76376 
>>>>>> UST-Id. DE 217652550
>>>>>>
>>>>>
>>>>> 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!
>>>>>
>>>>
>>>>
>>>> -- 
>>>> ____________________________________________________________________
>>>> artnology GmbH - Milastraße 4 - 10437 Berlin - Germany
>>>> Geschäftsführer: Ekkehard Blome (CEO), Felix Kuschnick (CCO)
>>>> Registergericht: Amtsgericht Berlin Charlottenburg HRB 76376 
>>>> UST-Id. DE 217652550
>>>>
>>>
>>> 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!
>>>
>>
>>
>> -- 
>> ____________________________________________________________________
>> artnology GmbH - Milastraße 4 - 10437 Berlin - Germany
>> Geschäftsführer: Ekkehard Blome (CEO), Felix Kuschnick (CCO)
>> Registergericht: Amtsgericht Berlin Charlottenburg HRB 76376 UST-Id. 
>> DE 217652550
>>
>
> 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!
>


-- 
____________________________________________________________________
artnology GmbH - Milastraße 4 - 10437 Berlin - Germany
Geschäftsführer: Ekkehard Blome (CEO), Felix Kuschnick (CCO)
Registergericht: Amtsgericht Berlin Charlottenburg HRB 76376 
UST-Id. DE 217652550


Mime
  • Unnamed multipart/mixed (inline, None, 0 bytes)
View raw message