openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gokhan Ergul <>
Subject Re: [jira] Commented: (OPENJPA-231) Incorrect handling of cascading bidirectional collections during merge/attach
Date Thu, 31 May 2007 21:57:35 GMT
Philippe Alexis wrote:
> Hi Gokhan,
> On 5/23/07, Gokhan Ergul <> 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 B@..."
>> 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:
> ____________________________________________________________________
> 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.

View raw message