Re: [jira] Commented: (OPENJPA-231) Incorrect handling of cascading bidirectional collections during merge/attach

[Philippe Alexis <ph...@gmail.com>]

Hi Gokhan,

I've read your reply to Reece in the thread about the 2nd take at the SQL
reordering patch.
I generally agree with all that you say. I'll also trust that the more
seasoned developers have
good reasons for not responding to this JIRA-231 issue; which hopefully will
become clearer
to me through further acquaintance with the way things work.

J-Philippe.

On 6/1/07, Gokhan Ergul <go...@telenity.com> wrote:
>
> Philippe Alexis wrote:
> > Hi Gokhan,
> >
> > On 5/23/07, Gokhan Ergul < gokhan.ergul@telenity.com> 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:
> > ____________________________________________________________________
> > 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.
> >
>
>

Re: [jira] Commented: (OPENJPA-231) Incorrect handling of cascading bidirectional collections during merge/attach

[Gokhan Ergul <go...@telenity.com>]

Philippe Alexis wrote:
> Hi Gokhan,
>
> I've read your reply to Reece in the thread about the 2nd take at the SQL
> reordering patch.
> I generally agree with all that you say. I'll also trust that the more
> seasoned developers have
> good reasons for not responding to this JIRA-231 issue; which 
> hopefully will
> become clearer
> to me through further acquaintance with the way things work.
>
> J-Philippe.
>

Hey Philippe,

I prefer to view silence of seasoned developers as a sign of how busy 
they are ;)

In any case, thanks for sticking with the issue, I appreciate your input.

Gokhan.