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:[EMAIL PROTECTED]
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:[EMAIL PROTECTED]
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:[EMAIL PROTECTED]
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
