DataNucleus JIRA is now in read-only mode. Raise any new issues in GitHub against the plugin that it applies to. DataNucleus JIRA will remain for the foreseeable future but will eventually be discontinued
Issue Details (XML | Word | Printable)

Type: New Feature New Feature
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Unassigned
Reporter: Andy Jefferson
Votes: 0
Watchers: 0

If you were logged in you would be able to see more operations.
DataNucleus Store RDBMS

Support for 1-N bidir relation between impl of interface with collection of elements

Created: 10/Jan/07 10:22 AM   Updated: 09/Apr/15 08:17 AM   Resolved: 07/Apr/15 12:47 PM
Component/s: ORM
Affects Version/s: None
Fix Version/s: 4.1.0.m4

File Attachments: 1. Zip Archive (5 kB)

 Description  « Hide
When we have

interface Container {}
class A implements Container
    Collection elements;
class B implements Container
    Collection elements;
class Element
    Container cont;

and the relation is bidirectional and we want to use a join table JPOX is currently incorrectly adding implementation FK columns to the Element table. It should operate just like a 1-N bidir

Sort Order: Ascending order - Click to sort in descending order
Andy Jefferson added a comment - 18/Apr/12 10:56 AM
Problem is in schema generation and is due to ReferenceMapping always generating columns. It needs to detect when part of a bidir relation with a join table.

Andy Jefferson added a comment - 18/Apr/12 11:52 AM
Testcase to demonstrate the situation. Test passes but creates additional FK fields in Element and doesn't create ReferenceMapping in join table

Andy Jefferson added a comment - 29/Oct/13 07:54 PM
Note that NUCRDBMS-700 fixed one particular 1-N FK interface case

Andy Jefferson added a comment - 30/Oct/13 12:51 PM
SVN trunk has some code in ReferenceMapping at the top, commented out that would generate correct schema now ... that is it has a ReferenceMapping in the element but with no datastore columns, and has the join table with a simple FK to the element. Note that it should *not* create a ReferenceMapping in the join table (as implied by comment above). The particular example above will have join tabled for A_ELEMENTS and B_ELEMENTS, and then to get the Element.cont it will need to (somehow) do a UNION of A_ELEMENTS and B_ELEMENTS (likely in FetchRequest).

Andy Jefferson added a comment - 07/Apr/15 12:47 PM
GitHub master passes this test