Salute, fellow hibernators.

Synopsis:
class Acquisition subclasses class Evidence using the 'Table per subclass' strategy ('joined-subclass') using foreign key 'evidence_id'. However Acquisition has its own surrogate primary key 'acquisition_id' in addition to the foreign key evidence_id.

Is there a way of mapping these classes such that:

and

both work? That is, acquisitionId/acquisition_id to effectively be also considered an identifier property of Acquisition.

Secondly, and related to this mapping problem, there is the question of classes that refer to the Acquisition subclass -- how should these be mapped? Since the Scan class has only a acquisition_id foreign key to Acquisition, and not to Evidence directly. Since Acquisition is effectively the top-level object/table of a wholly separate schema/object hierachy, we'd greatly prefer being able to work with & pass around acquisition_ids rather than having to force everything back to evidence_ids.

The linked exception occurs upon Session.save( aScan ), due to the incorrect Acquisition mapping as described above.

Thanks for reading.
Matt Harrison

Specifics below.

---------------

Hibernate version:


Mapping documents:

------------------ org/eurocarbdb/dataaccess/core/Evidence.hbm.xml ------------------


------------------ org/eurocarbdb/dataaccess/ms/Acquisition.hbm.xml ------------------


------------------ org/eurocarbdb/dataaccess/ms/Scan.hbm.xml ------------------



Code between sessionFactory.openSession() and session.close():


Full stack trace of any exception that occurs:


Name and version of the database you are using:


The generated SQL (show_sql=true):


Debug level Hibernate log excerpt:
(not given)

Any help would really be appreciated. Mapping objects to a subclass of another object seems like a common problem, however I've not seen or read any examples or discussions of how this should be mapped, since a standard mapping to the subclass does not work as expected.

problem remains... i emphasise that this boundary case is not covered by any of the existing documentation.

It sounds like you want Acquisition to have 2 primary keys. This is impossible. In your mappings evidence_id is the primary key of Acquisition. acquisition_id, as a second unique identifier generated by the db, seems utterly redundant.

You map the scans collection using the column name "acquisition_id". However, hibernate will populate this field with the primary key of the Acquisition i.e. the evidence_id, causing your key violation.

I draw the conclusion that you're mapping to a legacy schema. Is there any scope for making schema changes?

Thanks very much for your reply :-)

Indeed, we can make schema changes, but naturally we'd prefer not to. We have generally taken the approach of having a surrogate primary key on all tables, even join tables (since in the majority of cases we cannot exclude the possibility of adding columns at a later date). Having surrogate primary keys on all data tables at least seems like a normal & sensible practise. In our schema, acquisition_id is just a regular synthetic surrogate primary key, and evidence_id is the foreign key.

Perhaps I'm asking the question the wrong way around. Does hibernate require that the key used to join the subclass (ie: Acquisition) also be the primary key of the subclass' table? Because it seems like any not-null unique column that is a foreign key to the superclass' table (ie: Evidence) should suffice as the <key ...>?

The only drawback I can see is that other tables/classes that subclass Evidence could potentially refer to an evidence_id that is referenced by another subclass, but this possibility is easily checked for. Are there other compelling reasons why <key ...> must also effecitvely be the <id ...> of the subclass?

Currently, we can get the behaviour we're looking for by declaring acquisition_id as unique and using property-ref in all classes that are associated to Acquisition, I presume this is a Hibernate "hack"?

Thanks for reading.

Actually, when I ran your example code, evidence id is created as the primary key of the Acquisition table (using hibernate to generate schema). Evidence id in Acqusition is effectively a surrogate primary key (albeit aligned to the PK of a related table) so there's no need to add another.



Two objects can't share the same base class instance in Java so they won't be able to share the same row in the evidence table (assuming data is inserted via hibernate or at least conforms to the mappings).



A hack - no. property-ref is designed for such a situation where a relationship is defined by something other than the primary key. However, this is mainly for mapping to legacy schemas. If you control the schema its better to use the real primary key.