Re: Questions on Single Table Inheritance
Re: Questions on Single Table Inheritance
- Subject: Re: Questions on Single Table Inheritance
- From: David LeBer <email@hidden>
- Date: Wed, 30 Mar 2005 23:42:57 -0500
On Mar 30, 2005, at 11:18 PM, Owen McKerrow wrote:
Hi All,
Switching around one of my apps so that it use single table
inheritance. I've read up on it in Apple's "Using EOModler" and
Chuck's book, but I still have a couple of questions.
So I have a Member table ( will be parent ) and Im going to create to
Sub Tables, called Researcher and Student.
I thought that once I had created these sub-entities that I delete the
attributes from them that I don't want. e.g. we don't need the
students room number but we do need it for researcher, so I remove the
phone number from the Student entity. However EOModler then starts to
complain when I save it that the Sub-Table is missing one of the
parents attributes. can I just ignore this complaint ? Am I doing it
the right way ?
Nope.
The children need to implement all of the attributes of the parent (EOM
should show them in italics). The parent should only contain the
attributes that are applicable across all sub entities. Implement
attributes in the sub entities that are specific to them. The *table*
however needs to implement columns for *all* of the attributes used by
parent and children.
Using your example, if you don't need student room numbers, room
numbers should not be an attribute of Member, it should only be an
attribute of Researcher but there needs to be a *room number* column in
the *member* database table.
Also Im trying to figure out if I will need to have instances of
member ( i.e. the parent class will be concrete ). I will never just
make a "Member" they will always be either a Student or a Researcher
BUT I will need a combine array of the two of them, where I won't care
which type Im dealing with i.e. displaying the authors of a book,
written by both researcher and students.
And if I have to keep Member concrete does this mean I need to give it
a restricting qualifier ? i.e. its own value for the Type column ?
I think that it is required that the parent entity be abstract (I
haven't read the EOM docs on the subject recently, but that's what I've
done in the past). You will be able to refer to either Student or
Researcher as a Member (they are subclasses after all) you just won't
be able to refer to attributes specific to them using named methods.
ie: using the room number example from above:
Researcher researcher // assume exists
((Memeber)researcher).roomNumber(); will fail
((Member)researcher.valueForKey("roomNumber"); will work
And finally there is a table called Member_Details which has 2 BLOB's
in it ( its in its own table for efficiencies sake ), but only
researchers need an instance of this table. So Im assuming under
Member I make the relationship optional. And under researcher I would
then switch that to mandatory ?
Like attributes, if Member_Details is only applicable to Researchers,
model it only for Researchers, not for Members. Because Student and
Researcher map to the same db table it is necessary to implement
relationship constraints in the model not the database.
Hope that helps,
;david
--
David LeBer
Senior Systems Developer
PiMedia
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden