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.
Two simple tables, person and tagtype, in a ManyToMany relationship. The sql that generated the join table follows. Notice that each foreign key is specified with "on delete cascade". As expected, when the classes are generated, there is no class for the join table, and the person and tagtype classes have @ManyToMany annotations, see next. My reading of the spec is that there should be some cascade AnnotationElement for the ManyToMany. (Though I have not tried to build database with persistence.xml yet). Person.java @JoinTable(name = "PERSON_HAS_TAGTYPE", joinColumns = {@JoinColumn(name = "PERSON_ID", referencedColumnName = "ID", nullable = false)}, inverseJoinColumns = {@JoinColumn(name = "TAGTYPE_ID", referencedColumnName = "ID", nullable = false)}) @ManyToMany private Collection<Tagtype> tagtypeCollection; and Tagtype.java @ManyToMany(mappedBy = "tagtypeCollection") private Collection<Person> personCollection; CREATE TABLE ernie.person_has_tagType ( person_id INT NOT NULL , tagType_id INT NOT NULL , PRIMARY KEY (person_id, tagType_id) , CONSTRAINT fk_person_tagType_person1 FOREIGN KEY (person_id ) REFERENCES ernie.person (id ) ON DELETE CASCADE ON UPDATE NO ACTION, CONSTRAINT fk_person_tagType_tagType1 FOREIGN KEY (tagType_id ) REFERENCES ernie.tagType (id ) ON DELETE CASCADE ON UPDATE NO ACTION) ; CREATE INDEX fk_person_tagType_person1 ON ernie.person_has_tagType (person_id ASC) ; CREATE INDEX fk_person_tagType_tagType1 ON ernie.person_has_tagType (tagType_id ASC) ; eclipselink-2.0/derby Product Version: NetBeans IDE Dev (Build 200909111401) Java: 1.6.0_12; Java HotSpot(TM) Client VM 11.2-b01 System: Windows XP version 5.1 running on x86; Cp1252; en_US (nb) Userdir: C:\Documents and Settings\erra\.netbeans\dev
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.