« Return to Thread: Bidirectional relationship tests in the TCK

Re: Bidirectional relationship tests in the TCK

by Joerg von Frantzius-2 :: Rate this Message:

Reply to Author | View in Thread

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

 « Return to Thread: Bidirectional relationship tests in the TCK

LightInTheBox - Buy quality products at wholesale price!