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>
Query q = pm.newQuery(Subscriber.class);
q.setFilter("subscribable == :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.