Mailing-List: contact dev-help@openjpa.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@openjpa.apache.org
Received-SPF: pass (herse.apache.org: domain of philippe.alexis@gmail.com
 designates 66.249.82.234 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
        b=cFmLTi+9M+khvtN/RUEQgVQM3I5SPWWPiy/0RSvDV15u4tgAIE2smjjzE+omsoC/37KL0HAd3t5bWpWfRoOHxvAnpHa3l8Ij8iLmYpdtouvH0RiO0jwPl9m882xfKjd4RhAqi4rlqLfdmWbZpwVNvBamZWC3xPVbBrnyHBYCiMY=
Message-ID: <fb40f7d00706010915xac9cd24q3202e489f4aae087@mail.gmail.com>
Date: Sat, 2 Jun 2007 00:15:48 +0800
From: "Philippe Alexis" <philippe.alexis@gmail.com>
To: dev@openjpa.apache.org
Subject: Re: [jira] Commented: (OPENJPA-231) Incorrect handling of cascading
 bidirectional collections during merge/attach
In-Reply-To: <465F44CF.20500@telenity.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_5250_6946633.1180714548795"
References: <22866639.1177981695494.JavaMail.jira@brutus>
	 <27308434.1178136075518.JavaMail.jira@brutus>
	 <fb40f7d00705031317lc8af32ajc7063811496bfb15@mail.gmail.com>
	 <463A5C36.3090806@telenity.com>
	 <fb40f7d00705131229n4fb904e3rfba9b573646ff897@mail.gmail.com>
	 <4648FA33.6030601@telenity.com>
	 <fb40f7d00705170235m7ea8dcd3u4f838c4017b7129c@mail.gmail.com>
	 <46538EE2.8000603@telenity.com>
	 <fb40f7d00705311405h66849ea7t2f9240feb6e211f1@mail.gmail.com>
	 <465F44CF.20500@telenity.com>

------=_Part_5250_6946633.1180714548795
Content-Type: text/plain; charset=WINDOWS-1252; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

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 wil=
l
become clearer
to me through further acquaintance with the way things work.

J-Philippe.

On 6/1/07, Gokhan Ergul <gokhan.ergul@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=3DCascadeType.ALL)
> >    private Deity mother;
> >
> >    @OneToOne(cascade=3DCascadeType.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) whic=
h
> > 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 object=
s
> >> 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
> >
> > =95 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'.
> >
> > =95 If X is an entity merged to X', with a reference to another entity =
Y,
> > where cascade=3DMERGE
> > or cascade=3DALL is not specified, then navigation of the same associat=
ion
> > 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.
> >
>
>

------=_Part_5250_6946633.1180714548795--