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)

Key: NUCRDBMS-730
Type: Improvement Improvement
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Unassigned
Reporter: Andy Jefferson
Votes: 0
Watchers: 0
Operations

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

Persist of M-N relation can be inefficient; currently always does SELECT to see if present then INSERT.

Created: 21/Dec/13 11:36 AM   Updated: 21/Sep/14 08:13 PM   Resolved: 17/Sep/14 02:45 PM
Component/s: ORM
Affects Version/s: None
Fix Version/s: 4.0.3


 Description  « Hide
You typically get SQL like :-

SELECT 1 FROM CUSTOMER_SUPPLIER WHERE CID_OID=<2> AND SID_EID=<2>
INSERT INTO CUSTOMER_SUPPLIER (CID_OID,SID_EID) VALUES (<2>,<2>)

We have to consider all possible situations
1. persists delayed until flush, or persists done atomically
2. persist of an object with a M-N populated
3. persist of an object, then form the relation later
4. attach of an object with M-N
5. We want to allow the user to just set the non-owner side (JDO TCK requirement)

In the case of persists delayed until flush we will not know if the row has been added to the join table without a SELECT, since we cannot just check the collection on the other side (as both sides will be populated, and in the operation queue for processing).

Sort Order: Ascending order - Click to sort in descending order
Andy Jefferson added a comment - 17/Sep/14 02:45 PM
GitHub master improves the situation for pessimistic cases, and covers other situations better too now (though likely non-optimal still).

Further work could involve better processing in the OperationQueue and RelationshipManager so that with M-N we only push the owner side, and then the backing store will know to always persist when an add() comes in.