Issue Details (XML | Word | Printable)

Key: NUCRDBMS-17
Type: New Feature New Feature
Status: Open Open
Priority: Major Major
Assignee: Unassigned
Reporter: Andy Jefferson
Votes: 1
Watchers: 3
Operations

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

Classes with collection/map fields should be allowed to have "subclass-table" inheritance strategy, and the elements/keys/values should be allowed to have "subclass-table"

Created: 21/Aug/05 06:11 PM   Updated: 09/Mar/09 12:39 PM
Component/s: ORM
Affects Version/s: None
Fix Version/s: None


 Description  « Hide
Currently we don't allow a class with collections to be "subclass-table" inheritance strategy

Sort Order: Ascending order - Click to sort in descending order
Andy Jefferson added a comment - 24/Aug/05 07:11 PM
Schema generation (table, and constraint) now works for the join table collection case - the multiple owner tables are created, with the single join table, and element table, and FK's are added between all relevant id columns.

Andy Jefferson added a comment - 07/Oct/05 11:11 AM
JPOX CVS now supports collection fields that have elements using "subclass-table" and where there is no more than 1 subclass table storing the elements

CL Gilbert added a comment - 31/Jul/06 06:46 PM
This being the case, can we thrown an exception when more than 1 class extends the superclass where subclass-table is used and the superclass contains a collection? Currently the Enhancer completes fine, and the schema tool does not complain either. Yet at runtime if your lucky your program will fail quickly.


Also is there some difficulty is simply supporting this? Can't collection fields be put into the subclass just like ordinary fields? Manpower issue?

Andy Jefferson added a comment - 31/Jul/06 06:53 PM
> Can we throw an exception?

We can if someone has time to write the check to do that. Provide a patch ?

> Is there some difficulty providing this ?

Yes. Technical, and Manpower. Think about what the tables will look like with inheritance (at both ends) and then think about the queries that would have to be fired off to find elements in the collection (and how efficient they would be!). Go through the "org.jpox.store.rdbms.scostore" classes and see the TODOs.

Andy Jefferson added a comment - 08/Mar/09 04:19 PM
With the original backing stores the query to get the iterator of elements would have been

SELECT THIS.xxx FROM SUB1 THIS
WHERE THIS.OWNER_ID = val
UNION
SELECT THIS_1.xxx FROM SUB2 THIS
INNER JOIN SUB1 THIS_1 ON THIS_1.xxx = THIS.xxx
WHERE THIS.OWNER_ID = val

With the rewritten (SQL API) backing store the same iterator query becomes
SELECT 'mydomain.Sub2' AS NUCLEUS_TYPE,A0."NAME",A0.SUB2_ID
FROM SUB2 A0
WHERE A0.OWNER_ID = val
UNION
SELECT 'mydomain.Sub1' AS NUCLEUS_TYPE,A0."NAME",A0.SUB2_ID
FROM SUB1 A0
WHERE A0.OWNER_ID = val

So it is more correct now, but unfortunately gets the "id" field name incorrect since should be selecting columns of SUB1 in the first part of the union, and columns of SUB2 in the second part of the union.

The size() query and many other queries still have TODOs for anyone interested

Andy Jefferson added a comment - 09/Mar/09 12:39 PM
The query iterator for elements is now correct in SVN trunk for the case of FK set. Also elements are now correctly inserted for that case.