Philippe Alexis wrote:
Hi Gokhan,
On 5/23/07, Gokhan Ergul < [EMAIL PROTECTED]> wrote:
Philippe Alexis wrote:
The question is.. Why does OpenJPA expect, even force, the users to
> allocate for cascading from child to parent regardless of whether they
mean to or not?
I don't think that's the intention, but it's just a glitch.
In the source code, the Deity "relations" example has the following:
@OneToOne(cascade=CascadeType.ALL)
private Deity mother;
@OneToOne(cascade=CascadeType.ALL)
private Deity father;
The way I see it, OpenJPA is telling users that *they* are doing
something
wrong when they merge
a new parent entity that cascades to its child (also a new entity) which
doesn't annotate its parent
with cascade.
I don't follow you here --it's just an example which illustrates a
certain usage pattern. I'm sure there are other examples where child
entities do not cascade to parent entities. And the fact of the matter
is, it works just fine for one generation (A to B), just not beyond one
generation (A to B to C).
There's that, and regarding your mentioning "catching free-riders"
The way I see it, the intent of "Encountered new object [EMAIL PROTECTED]"
exception is to catch freeriders, iow, to prevent attaching new objects
where there's no defined cascade-merge relation from (the set of)
currently attached object(s).
here's what the JPA specification has got to say:
____________________________________________________________________
3.2.4.1 Merging Detached Entity State
• If X is a new entity instance, a new managed entity instance X' is
created
and the state of X is
copied into the new managed entity instance X'.
• If X is an entity merged to X', with a reference to another entity Y,
where cascade=MERGE
or cascade=ALL is not specified, then navigation of the same association
from X' yields a
reference to a managed object Y' with the same persistent identity as Y.
____________________________________________________________________
According to the implementation, in the latter case, Y would
necessarily be
detached;
the use-case presented by you shows that it needs not be.
As you point out, spec defines the expected behavior when Y has a
persistent identity, not the case when Y doesn't have it. So the latter
case is left to implementations (or better, a new version of the spec
which covers that as well). Throwing an exception in that case is a
sensible choice imho, except I'm trying to prove that the restriction
should not apply in that particular use-case due to the fact that the
"new" object is already attached.
Based on the specification, if a new entity B as parent didn't cascade to
its new child C,
and the user attempted a merge(b), the problem shouldn't be about that
there's no cascading
specified, but that there's no managed entity C' .
The advice about cascading would then be just that, an advice.
Well, I wouldn't exactly call that advice, since you'd fail the TCK
tests if you don't follow it ;)
As I mentioned above, we don't have a problem with what the spec says,
but rather with what it doesn't say.
J-Philippe.
