As I think about this a little more...
If you're talking about the inheritance chain, JPA appears to derive
that from the java inheritance hierarchy. It's not explicitly
defined.
On Mon, May 31, 2010 at 7:48 AM, Mike Kienenberger <mkienen..mail.com> wrote:
> Here's what we're using for JPA:
>
> // Contact Detail (root)
>
>..nheritance(strategy = InheritanceType.JOINED)
>..iscriminatorColumn(name="object_type")
>..rimaryKeyJoinColumn(name="id", referencedColumnName="id")
>
> // Address (subclass)
>
>..iscriminatorValue("ADR")
>
>
> I guess JPA allows another approach, which would be to specify sql for
> each subclass instead of a column value.
>
> Reviewing what's out there already for single-table inheritance (which
> I've never used before), I don't see any changes that are needed.
> Everything that works for single-table seems to be sufficient and
> necessary for vertical inheritance.
>
> As far as I can tell, the implementation difference between
> single-table and vertical is only that multiple tables are involved in
> the queries for reading and writing the data.
>
> I didn't completely understand the question, so I'm not sure if this answers it.
>
> As I read through the JPA specs, I note that it does not support mixed
> inheritance types for a set of tables as a required feature. This
> could be future work if we decided we wanted to support it.
>
> On Sun, May 30, 2010 at 1:44 PM, Andrus Adamchik <andru..bjectstyle.org> wrote:
>> Approaches to Mapping Inheritance
>> ---------------------------------
>>
>> Currently we don't require users to specify inheritance semantics
>> explicitly. We guess it instead (not unlike EOF). Just select a superclass
>> ObjEntity and (optionally) subclass DbEntity and we'll derive the rest. In
>> case of vertical inheritance I wrote the code to determine the inheritance
>> DbRelationship out of all relationships between the super and sub tables
>> (1..1 PK-based relationship).
>>
>> JPA for instance does require explicit inheritance semantics property set on
>> the superclass. Should we do the same for sanity sake? E.g. to prevent
>> unsupported combinations of inheritance types in a single hierarchy. I don't
>> know what those unsupported combinations will be at the end (i.e. how smart
>> our algorithms will end up being and how extensive the test suite we'll have
>> to say what is supported and what's not). Having a hard rules (with
>> validation done by the Modeler) will make things much less ambiguous (at the
>> expense of some flexibility). E.g. back in the EOF days I barely used
>> inheritance, as it was all based on implicit mapping rules between super and
>> subclasses, so I never bothered to understand them (did it also require to
>> flatten super attributes?? My current design won't).
>>
>> Thoughts on that?
>
This archive was generated by hypermail 2.0.0 : Mon May 31 2010 - 11:59:09 UTC