Even though "abstract" is set to "true" DDL is generated to create a table for an abstract class mapping. The Java class is marked as abstract and there are 2 concrete classes also mapped (one is below). Each Java class (abstract and the 2 concrete) have separate mapping files.

Also why do I have to

I'm using org.hibernate.tool.hbm2ddl.SchemaExportTask to generate the DDL.

Thx for any help you can give,

Dan

<!-- code from abstract mapping file -->
<joined-subclass
name="AbstractRepositoryFeature"
extends="RepositoryObject"
abstract="true">

<key column="ID" />

<property
name="index"
column="NDX"
type="integer"
not-null="true">
</property>

<property
name="lowerBound"
column="LOWER_BOUND"
type="integer"
not-null="false">
</property>

<property
name="upperBound"
column="UPPER_BOUND"
type="integer"
not-null="false">
</property>

<many-to-one
name="datatype"
class="RepositoryObject"
column="DATATYPE_ID">
</many-to-one>
</joined-subclass>

<!-- code from concrete class mapping file -->
<joined-subclass
table="MMR_REFS"
extends="AbstractRepositoryFeature"
name="RepositoryReference">

<key column="ID" />

<property
name="containment"
column="IS_CONTAINMENT"
type="boolean"
not-null="false">
</property>

<many-to-one
name="opposite"
class="RepositoryObject"
foreign-key="OPPOSITE_ID">
</many-to-one>
</joined-subclass>

abstract="true" does not affect DDL: if it did, table-per-class-hierarchy mixed with table-per-subclass wouldn't work. If the abstract superclass genuinely has no dedicated table, then don't give it a table="tablename" attrbiute. That'll prevent DDL generation for it.

Thx for your quick response. There is no "table" tag on the abstract class. Please note the first mapping file below does NOT have that tag. Only the joined-subclass mapping file that "extend" the abstract joined-subclass does.

<!-- code from abstract mapping file -->
<joined-subclass
name="AbstractRepositoryFeature"
extends="RepositoryObject"
abstract="true">

<key column="ID" />

<property
name="index"
column="NDX"
type="integer"
not-null="true">
</property>

<property
name="lowerBound"
column="LOWER_BOUND"
type="integer"
not-null="false">
</property>

<property
name="upperBound"
column="UPPER_BOUND"
type="integer"
not-null="false">
</property>

<many-to-one
name="datatype"
class="RepositoryObject"
column="DATATYPE_ID">
</many-to-one>
</joined-subclass>

<!-- code from concrete class mapping file -->
<joined-subclass
table="MMR_REFS"
extends="AbstractRepositoryFeature"
name="RepositoryReference">

<key column="ID" />

<property
name="containment"
column="IS_CONTAINMENT"
type="boolean"
not-null="false">
</property>

<many-to-one
name="opposite"
class="RepositoryObject"
foreign-key="OPPOSITE_ID">
</many-to-one>
</joined-subclass>

It's the <class> mapping that I'm talking about, not any of the <joined-subclass> mappings. What does that look like?

Okay, we've changed things a little bit from the first post. Let me first fully explain what we're trying to do. We have a set of concrete objects, RO, that we wish to be mapped to a table. There is also a abstract subclass of RO called ARF, for which there are 2 concrete sublcasses (and thus tables), RR and RA. We want the concrete tables for RR and RA to each contain the columns defined by ARF, but not those defined by RO. In other words, we want to join with RO, but union with ARF. Here are the latest mappings we have (which produce the unwanted "ARF" table):

<class
name="RO"
table="RO">

<id
name="id"
type="long"
column="ID">
<generator class="increment"></generator>
</id>

<property
name="A"
column="A"
type="string"
not-null="false"
length="64">
</property>
</class>

<joined-subclass
name="ARF"
extends="RO"
abstract="true">

<key column="id" />

<property
name="B"
column="B"
type="integer"
not-null="true">
</property>
</joined-subclass>

<union-subclass
table="RR"
extends="ARF"
name="RR">

<property
name="C"
column="C"
type="boolean"
not-null="false">
</property>
</union-subclass>

<union-subclass
table="RA"
extends="ARF"
name="RA">

<property
name="D"
column="D"
type="boolean"
not-null="false">
</property>
</union-subclass>

The rest of the resulting DDL is exactly what we want; the RR and RA tables contain the columns defined in their own and the ARF mappings, but not the RO mapping (except the ID, of course). The only problem seems to be a table for the ARF mapping also gets generated.

Working in abbreviations and acronyms gives me headaches. It will also earn you the undying hatred of whoever has to maintain your mappings and schema after you've found another job.

I'm not sure that hiberante supports abstract subclasses of concrete classes. I've never tried to implement that. Assuming that your assertions are correct, and all of these relations are "is-a" and "kind-of", but not "is-a-role", then I'd probably implement this as an abstract superclass (no table) that has three concrete subclasses: the one that stored in RO and not any other table; the one that is stored in RO and in RR; and the one that is stored in RO and RA.

Perhaps you should consider delegation instead of inheritance, as these relationship seem to be to be anything but self-documenting.