Hi Ari,
On May 31, 2007, at 12:21 AM, Aristedes Maniatis wrote:
>
> 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.
No, I'm suggesting to look at the database schema to find the cases
of foreign key == primary key.
And I don't think there is any need for two different fields to
represent the columns in the database that because of foreign key
constraints will always contain identical values.
> 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?
I'm a bit unclear what this scenario means. If they want to add
Person as a superclass, I would say they need to remap the classes so
that the field in the superclass Person corresponding to the primary
key columns is the identity field and there is no longer any identity
field in the subclasses.
>
>
>>> 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 this is a requirement, I'd recommend against mapping this schema
as inheritance. I'd map it as a one-to-zero-or-one relationship. Then
it's easy to delete the "subclass" instance while leaving the
"superclass" instance intact.
> 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?
I'm suggesting that the tool that generates the Java model from the
database schema should be configurable to recognize the specific
pattern of table2 having a primary key == foreign key to table1 and
generate an inheritance relationship of class2 extends class1. If the
requirement is to be able to independently manage instances of class1
and class2, then the tool should be able to map this pattern as a one-
to-zero-or-one relationship.
And just so it's clear, I'm not an expert in Cayenne [or EOF]. I'm
only offering suggestions based on a few years of doing enterprise
ORM. And the closer you are to being concept-compliant with JPA and
JDO, the more your users will be able to use other standards.
Reusable programmers is still a viable objective.
Craig
>
>
> 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
>
>
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 - 14:47:18 EDT