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


Attachment: PGP.sig
Description: This is a digitally signed message part

Reply via email to