On 31/05/2007, at 4:59 PM, Craig L Russell wrote:
> If it really is an inheritance relationship and not a one-one or
> one-many relationship, the compound primary keys should also
> correspond exactly.
Then you are suggesting that we use the name of the attribute in the
two ObjEntities as the mechanism to see which pairs correspond. My
point is only that the names should not be special, particularly when
a user might be refactoring an existing database scheme. Say the user
has:
Student.studentKey and Tutor.tutorKey as the PK attributes for their
existing project. (Not the way I'd do it, but...)
Now they want to add Person as a superclass. You are saying this
should not be allowed without renaming the existing attributes?
>> Also, as Lachlan points out, this means that we don't get to
>> specific nullify, cascade, etc delete rules. If you have a
>> concrete superclass, you may wish to nullify the relationship when
>> deleting the subclass record. Naturally if the superclass is
>> abstract this is not allowed. But specifying the objrelationship
>> explicitly allows us to put these rules somewhere and remove any
>> ambiguity from compound key relationships.
>
> This seems like an implementation detail (which I am very obviously
> not competent to comment on).
Well, it is a functionality decision. Do we want users to be able to
delete the subclass without deleting the superclass? If the
superclass is concrete why not allow that to happen? And in that
case, we need to store the relationship attributes somewhere.
Thankfully, we already have a mechanism to do this.
I'm not 100% clear on what you are proposing. Is it that Cayenne
should be able to construct the appropriate JOIN by looking just at
the PK flag s on the attributes in question, without needing any
other information stored in XML in the model? If so, why is that
better than storing the (possibly redundant, but not always)
information in the XML datamap file?
Ari Maniatis
-------------------------->
Aristedes Maniatis
phone +61 2 9660 9700
PGP fingerprint 08 57 20 4B 80 69 59 E2 A9 BF 2D 48 C2 20 0C C8
This archive was generated by hypermail 2.0.0 : Thu May 31 2007 - 12:21:57 EDT