Hi there,
On 31/05/2007, at 1:03 PM, Craig L Russell wrote:
On May 30, 2007, at 7:23 PM, Lachlan Deck wrote:
On 31/05/2007, at 11:54 AM, Lachlan Deck wrote:
On 31/05/2007, at 10:44 AM, Mike Kienenberger wrote:
On 5/30/07, Aristedes Maniatis <[EMAIL PROTECTED]> wrote:
When we get to vertical inheritance there will be at least one
other
property added to the ObjEntity: the name of the relationship
used to
find the superclass.
When we get to inheritance, we'd be wise to follow the JPA
methodology
for specifying inheritance relationships. Vertical and single-table
is well-defined.
<...>
Okay, so consider the request for superRelationship dropped. (See
disclaimer :-) Well that makes it simpler to do all of this ;-)
Hang on... Hibernate, for example, does indeed utilise a
relationship, to my understanding [1], that specifies the nature
of the relationship to the parent, what happens when an object is
deleted and so on. These are characteristics that are encapsulated
in a relationship. This is why the request for defining a
superRelationship in ObjEntity was first made. Perhaps it's an
optional for vertical where in its absence is some implicit strategy.
Thoughts?
The example below shows in Hibernate how to remove the
automatically generated relationship between Person and Employee
due to the need to map the primary key association to inheritance.
I'd even call this a deficiency in the tool, since there is a
foreign key constraint defined on the primary key column of the
employees table that refers to the primary key column of the
persons table. The most natural mapping of this would be
inheritance and should therefore be the default.
While it might be possible theoretically to define a different
column in the database to be used as the association column to join
rows of a subclass and a superclass table, by far the most common
and most understandable way to map inheritance is to simply assume
that the primary key of both tables is the same and that the id
field in the class contains the value to be used for both primary
keys. The direction of the foreign key constraint should indicate
which is the subclass.
Sure. (talking from EOF experience again...) the EOF docs for
vertical talked about the need for creating a relationship for the
case where the tables already exist (and thus their names, for
example, may differ) and you're wanting to introduce inheritance
(though in practice it needed the relationship either way but that's
irrelevant here).
However, my question remains this: if not defined in a relationship
where does the developer define the delete rules etc? Or are you
suggesting they don't get an option?
with regards,
--
Lachlan Deck
