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: Bug Bug
Status: Closed Closed
Resolution: Cannot Reproduce
Priority: Testcase Required Testcase Required
Assignee: Unassigned
Reporter: Chris Colman
Votes: 0
Watchers: 0

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

Ambiguous storage of FK value when interface implemented by hierarchy with more than one level of concrete classes

Created: 22/Jul/10 03:58 AM   Updated: 19/Jun/15 02:35 PM   Resolved: 19/Jun/15 12:44 PM
Component/s: None
Affects Version/s: 2.0.4
Fix Version/s: None

Windows or Linux
JDK 1.6

Datastore: MySQL
Severity: Production

 Description  « Hide
For the following class diagram:

ISubscribable (interface) <--------------------- Role
^ | ^
Periodical (concrete class) ----* (0..m) Subscriber (concrete class)
Newsletter (concrete class)

The following columns (and others) were generated in Subscriber table:

subscribable_periodical_periodical_id_eid, subscribable_newsletter_periodical_id_eid, subscribable_magazine_periodical_id_eid

When persisting a subscriber subscribed to a Newsletter I saw that sometimes the
subscribable_periodical_periodical_id_eid column was set but in other circumstances the subscribable_newsletter_periodical_id_eid column was set. At no time was a Periodical ever instantiated - only Newsletter objects were instantiated.

This caused havoc with a query that was run later:

2010/07/22 10:33:45.220 DEBUG [DataNucleus.Datastore.Native] SELECT a0.subscribable_periodical_periodical_id_eid,a0.version FROM role a0 WHERE a0.role_id = <3853>

by executing:

Query q = pm.newQuery(Subscriber.class);

q.setFilter("subscribable == :periodical");

return q.execute(periodical);

The query always used the subscribable_periodical_periodical_id_eid column which would fail on those instances that had populated the other column.

To make the storage of the FK deterministic I had to make Periodical an abstract class. This caused all new instances to populate the newsletter column instead of some occassionally populating the periodical column.

I'm not sure if this is a bug in relation to persistent interfaces or whether it is impossible for DN to tell what column it should be populating because the above schema is implicitly ambiguous in relation to it's persistence using DN.

The problem has been solved by making the Periodical class abstract but I thought I'd register this issue so that it can be analysed at some time in the future.

Sort Order: Ascending order - Click to sort in descending order
Chris Colman added a comment - 22/Jul/10 04:01 AM
That ASCII class diagram didn't present as expected. Here's a 'word' version:

ISubscribable is an interface
Periodical implements ISubscribable
Newsletter implements Periodical
Subscriber extends Role
Subscriber has a reference to persistent interface ISubscribable
Periodical has 0..m Subscribers

Chris Colman added a comment - 22/Jul/10 04:59 AM
Are the multiple columns really necessary in the first place? The query code doesn't seem to think so - it thinks it's sufficient to base the query on the Periodical class - the class that is directly implementing the interface - and so use the subscribable_periodical_periodical_id_eid column.

Certainly the extra columns seem redundant in a 'columns in superclass' inheritance mapping strategy.

The fact that these other columns even exist is puzzling to me and the fact that the storage code ambiguously uses them is causing some confusion.

Andy Jefferson added a comment - 20/Sep/10 01:41 PM
No testcase

Andy Jefferson added a comment - 19/Jun/15 12:44 PM
Can't see this. When I have an interface and one implementation has a subclass then the subclass has no FK as part of the interface mapping.

Kindly provide a way of reproducing this (aka testcase, a valid one, following the testcase guide) and it can be reopened.