This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Summary: | "Enitty Classes from Database" missed cascade specification in m:n relationship | ||
---|---|---|---|
Product: | javaee | Reporter: | err <err> |
Component: | Persistence | Assignee: | Sergey Petrov <sj-nb> |
Status: | RESOLVED INVALID | ||
Severity: | blocker | ||
Priority: | P3 | ||
Version: | 6.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: | |
Attachments: | files showing the issue |
Description
err
2009-09-12 23:12:22 UTC
can you point me to specification section and provide sql for all tables? I'm reading and have no full view yet but for example there is "The relationship modeling annotation constrains the use of the cascade=REMOVE specification. The cascade=REMOVE specification should only be applied to associations that are specified as One- ToOne or OneToMany. Applications that apply cascade=REMOVE to other associations are not por- table." but ManyToMany annotation have cascade element, so may be cascade should work (This JPA stuff is very cool, but I am totally new to JPA of any version (and limited db experience). I'm still struggling to understand how all the pieces fit together... I'll send the stuff you requested later in the day when I have some time... I attaching a zip with all the stuff. Things to note: - all the foreign key constraints have "ON DELETE CASCADE" - the files in src/o2 have CascadeType.ALL scattered around - the files in src/o1 have no CascadeType spec Honestly I don't understand exactly what CascadeType.REMOVE relationship is to the on delete cascade. If they are not the same will persistence data and/or optional cache get out of sync with the data base? Is CascadeType.REMOVE used when building a database (if the create database strategy is selected). Maybe "orphanRemoval true" is the right way to handle "on delete cascade". The sql to create the tables is in sql directory. 4 tables are created. test-tables.sql:2:CREATE TABLE chart ( test-tables.sql:8:CREATE TABLE event ( test-tables.sql:14:CREATE TABLE chart_event ( test-tables.sql:34:CREATE TABLE displayAspects ( ((note the o1 and o2 directories can't exist together in a real setup since they reference the same entities, i'm just packaging it this way)) Run Entity from database and you get src/o2/Chart.java src/o2/Displayaspects.java src/o2/ChartEvent.java src/o2/DisplayaspectsPK.java src/o2/ChartEventPK.java src/o2/Event.java drop the displayAspects table, rerun and you get src/o1/Chart.java src/o1/Event.java Created attachment 87714 [details]
files showing the issue
thanks, investigating, do you have sample for any side effects from missed cascade annotation? I'm just starting some unit test on the database/JPA. I'll see what I can come up with, but it won't be real soon, I need to fully read the spec I think. > effects from missed cascade annotation? I wish I could authoritatively say what should or should not be there in which circumstances. Things are not acting like I think they should right now in my stuff; and I need to investigate that. I wonder why CascadeType.ALL is used in some cases and not others in the generated entities? In issue 172098 there is the the question of CascadeType.PERSIST. There are the several types included in ALL and I'm trying to understand them now. Maybe issue 172098 should be about cascade types in general and what good defaults should be. This issue may be invalid about needed a cascade spec. I just found the following in the spec. > If the remove operation is applied to a managed source entity, the remove operation will be > cascaded to the relationship target in accordance with the rules of section 3.2.3, (and hence it is > not necessary to specify cascade=REMOVE for the relationship)[19]. thanks. regarding my question it was mostly related to severity of the issue if it's p2. > mostly related to severity of the issue if it's p2
When I first noticed the difference between how a simple n:m was annotated, and annotation of an n:m with additional
table hanging off the join table I thought there was a big problem, but now I don't know until I better understand what
is going on.
That cascade=PERSIST issue 172098 might actually be more important than this issue. And maybe what is needed is a new
issue like "Correct defaults for cascade=" which should be P2. It seems like I know less than I did last week, I hope
that means I'm close to knowing more.
ok, let it be p3, as you said it may be invalid and even if it's valid it's not yet clear if there will be anything worth P2, feel free to rise if you'll find more details or do not agree Now that I'm somewhat more familiar with this stuff I believe that where the cascade stuff is used in these situations is correct. There still a bug wit the use of CascadeType.ALL (i think). I believe only CascadeType.REMOVE is appropriate for managing SQL's "ON DELETE CASCADE". As discussed elsewhere, I think enabling/disabling Cascadetype.PERSIST should have nothing to do with REMOVE. One thing I did not try was to create the tables and foreign keys without the "ON DELETE CASCADE" and verify that CascadeType.REMOVE is not used. And forget that quote at the end of the comment of "Wed Sep 16 16:14:08", it only applies when orphanRemoval is set. What I see from specification CASCADE.DELETE may be used in case of ON DELETE CASCADE but there is no requirement or required mapping between this specification and database property. I'm still investigation if I miss something. i'm trying to reinvestigate this issue
and it seems according to my statement regarding
"cascade=REMOVE specification should only be applied to associations that are
specified as One-
ToOne or OneToMany"
and statement:
"This issue may be invalid about needed a cascade spec. I just found the
following in the spec.
> If the remove operation is applied to a managed source entity, the remove operation will be
> cascaded to the relationship target in accordance with the rules of section 3.2.3, (and hence it is
> not necessary to specify cascade=REMOVE for the relationship)[19]."
and latest one "There still a bug wit the use of CascadeType.ALL (i think)" but code generated for initial case/tables do not contain any cascade specification, so it's another cases, I'm closing this one as invalid, but feel free to reopen if I miss something.
|