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 <ar..aniatis.org> 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
This archive was generated by hypermail 2.0.0 : Wed May 30 2007 - 23:20:16 EDT