Hi Lachlan,
On May 30, 2007, at 8:19 PM, Lachlan Deck wrote:
> 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).
Well, from the database perspective there is a difference based on
the direction of the foreign key. In general, a subclass table
contains the foreign key constraint. There might be several subclass
tables, all of which have foreign key constraints on the primary key
column of the superclass table.
The specific case where there is always a row in each of the tables
simply means that there are no other subclasses involved. And in
fact, many ORM solutions offer a special case mapping for this, that
doesn't involve relationships at all.
>
> 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?
In an inheritance situation, there is only one instance corresponding
to the rows (one row in each table in the hierarchy). I'm suggesting
that there is no option. If the instance is deleted, then the row in
each table is deleted.
Craig
>
> with regards,
> --
>
> Lachlan Deck
>
>
>
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russel..un.com
P.S. A good JDO? O, Gasp!
This archive was generated by hypermail 2.0.0 : Thu May 31 2007 - 11:21:37 EDT