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