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.
Refer to issue 172075 for a picture of the ER diagram. (This issue also bears a relationship to that issue) In that diagram, chart_has_event is a join table, m:n mapping, for chart and event (event is not pictured, it is represented by the line that goes up from chart_has_event). However, as seen following, the "Entity Classes from Database" action produced an EntityClass named ChartHasEvent.java, instead of doing @ManyToMany in Chart.java and Event.java. This is rather cumbersome to use. Chart.java @OneToMany(cascade = CascadeType.ALL, mappedBy = "chart") private Collection<ChartHasEvent> chartHasEventCollection; Event.java @OneToMany(cascade = CascadeType.ALL, mappedBy = "event") private Collection<ChartHasEvent> chartHasEventCollection; ChartHasEvent.java @JoinColumn(name = "CHART_ID", referencedColumnName = "ID", nullable = false, insertable = false, updatable = false) @ManyToOne(optional = false) private Chart chart; @JoinColumn(name = "EVENT_ID", referencedColumnName = "ID", nullable = false, insertable = false, updatable = false) @ManyToOne(optional = false) private Event event; Assuming that a @ManyToMany is generated (Please! :-) ), and that there is something like a ChartHasEventPK. Two convenience methods would be Chart.java public ChartHasEventPK getPK(Event event) { return new ChartHasEventPK(this, event); } Event.java public ChartHasEventPK getPK(Chart chart) { return new ChartHasEventPK(chart, this); } And this PK could be used with most of the other tables seen in the diagram with issue 172075. But these could easily be added locally by me by extending Chart and Event. 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
I want to rephrase this. If there are tables A, B, A_B where A_B is a join table, then this is the classic n:m and is generated as @ManyToMany and there are methods A.getBCollection() and B.getACollection(). If you add a table C which keys to A_B then the situation is generated differently. Now that I'm looking at specifics in this area, this issue is mostly about missing the methods A.getBCollection() and B.getACollection() when table C is added. The rest of the generated stuff seems appropriate (but I'm still investigating). I'm exploring how to best create these missing methods (using some named queries or additional annotated fields/properties or...) (if you have any suggestions or thoughts ...). (It is also true that when table C is added, that cascade=ALL is used, that ALL has a bunch of stuff in it which I'm still sorting through)
Created attachment 87946 [details] ER diagram for describing problem
For starters, assume there is no aspectsDisplay table in the diagram. This is an n:m relationship and considering only the Chart entity, you get a field Collection<Event> with methods getEventCollection() setEventCollection() If you then add a new table to the schema, you loose the m:n *and* the 'Collection<Event>' and methods (and your code that uses them has problems). There are various ways to deal with this. What I've chosen is that in the Chart entity add a field Map<Event, Aspectdisplay> with get/set map methods. This actually does a pretty good job of capturing the semantics of the ER diagram. And retain the m:n mapping and code compatibility. Downside is that acc'd to the spec, a Map should only be on one side of a bi-directional relationship. But that is not an issue for me. Here's what I'm using. @OneToMany @JoinTable(name = "DISPLAYASPECTS", joinColumns = {@JoinColumn(name = "CHART_ID", referencedColumnName = "ID", nullable = false , insertable=false, updatable=false)}) @MapKeyJoinColumn(name = "EVENT_ID", nullable=false ,insertable=false, updatable=false) private Map<Event, Aspectdisplay> aspectdisplayMap; This works ok for reading. For writing/creation, if you simply add the Aspectdisplay entity to the map, there is a problem when the cascaded persist updates the map, I've filed https://bugs.eclipse.org/bugs/show_bug.cgi?id=289925. The workaround is simple, persist the Aspectdisplay entities instead of adding them to the map, then do "em.refresh(theChart)" and the map is correctly built.
sorry for 4 years evaluation, but currently I see there is not enouth details. from er diagram I see 4th table, and in relation to this 4th table, suspected join table is not a join table, but something strange like a duplicate of aspectratio table but without third column. it may prevent detection of join table as a join table, as you have to create this relationship to some actual table instead of join. also filed eclipselink issue is now: Status: CLOSED INVALID it seems model isn't good in this case as it even can't be handled by eclipselink properly and just doesn't look good at all, in this case entities generation can't handle it also. if you are still interested in and have some more ideas, feel free to argue. also attach sql script to create all tables may help with additional evaluation.