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.
The current mechanism for generating entity classes from a database creates JavaBean properties for both directions of a one-to-many relationship (in JPA terms, it assumes a bidirectional relationship), even though the database itself has enough information to infer that a unidirectional relationship *might* be more appropriate. As an example, the "Travel Center" database includes several relationships that reflect this. Abridged versions of the table creation DDL: create table travel.TripType ( TripTypeID INTEGER NOT NULL, ... ); alter table travel.TripType add constraint travel_TripTypePK PRIMARY KEY (TripTypeID); create table travel.Person ( PersonID INTEGER NOT NULL, ... ); alter table travel.Person add constraint travel_PersonPK PRIMARY KEY (PersonID); create table travel.Trip ( TripID INTEGER NOT NULL, PersonID INTEGER NOT NULL, TripTypeID INTEGER NOT NULL, ... ); alter table travel.Trip add constraint travel_TripPK PRIMARY KEY (TripID); alter table travel.Trip add constraint travel_TripPersonFK FOREIGN KEY (PersonID) REFERENCES travel.Person (PersonID); alter table travel.Trip add constraint travel_TripTripTypeFK FOREIGN KEY (TripTypeID) REFERENES travel.TripType (TripTypeID); From a logical viewpoint, the Person<->Trip is bidirectional, while the Trip<->TripType relationship is unidirectional (TripType is just a domain table listing the valid trip types; if you wanted all trips of a particular type across all persons, you could just query the Trip table and filter on TripTypeID). The question is, how could the generator distinguish these cases? It may not actually be possible to make this distinction accurately. In that case, it would be great if the UI of the generator could visualize all of the potential relationships among the entity classes to be created, and allow the user to pick the type of relationship that should be represented in the generated entity classes (including the ability to remove a relationship that is physically represented in the database, but is unlikely to be used in the corresponding JavaBeans objects).
Hmmm... I just ran into this issue in NB 6.8. After all these years (:-) I realized that the bidirectional nature of the relationships causes the persistence of one type to trigger reading in all of those types in the database. In my case, the wizard generated code for "create" of the type has fragments such as if (filetype != null) { filetype.getFileCollection().add(file); filetype = em.merge(filetype); } (file is my type, not the Java File) file is ManyToOne to filetype, and filetype is OneToMany to file. Since file has a filetype, this causes filetype to get the entire file Collection in the database. There can be a LOT of files in the database. Each of the nicely normalized columns in file has such a relationship, which means that the code gets all the files in the database times the number of these normalized columns, for every file which is persisted. I think this is the same issue as is described in this Bug. What do I do about this?
This old bug may not be relevant anymore. If you can still reproduce it in 8.2 development builds please reopen this issue. Thanks for your cooperation, NetBeans IDE 8.2 Release Boss