Re: Abstract Entities [Was: Modelling improvements: inheritance + interfacing (Draft)]

[Lachlan Deck <la...@gmail.com>]

Hi Craig,

On 31/05/2007, at 11:46 PM, Craig L Russell wrote:

> 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.

Good point. I think that's exactly what we've been suggesting (for  
vertical inheritance) except that such constraints are not  
necessarily always within the RDBMS but within the Cayenne model.

> 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.

Perhaps that assumes that there are indeed such constraints in the  
database (which is not always the case). You'd naturally hope for  
that to be the case in normal circumstances but it's also possible to  
impose in-memory constraints within Cayenne, EOF, or (I assume) any  
other ORM system.

>> 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.

Ahh, I think I see where we're coming at this differently (maybe,  
correct me if I've misunderstood you :-). The only place where the  
primary/foreign keys are defined (or remapped) with Cayenne (or EOF  
for that matter) are within the model; not within the java classes as  
they are deemed database artefacts that the user is unaware of in  
normal circumstances. There is nothing in code (unless you choose to  
expose the primary/foreign key(s) as class attributes) that tells the  
programmer what the name of the primary key is. It's usually irrelevant.

Thus the normal rules of inheritance-within-java is a different  
scenario where it is indeed impossible to change the signature of an  
inherited attribute/method. Here, there is no signature to change -  
they're only known to the Cayenne runtime as defined in the model.

Within the modelling environment we're essentially creating "is-a"  
relationships. So the question being discussed here is how is that  
relationship defined? The answer to that question depends upon the  
type of inheritance chosen.

For vertical (or Inheritance.JOINED), for example, at runtime I'm  
envisaging (based upon EOF experience) that Cayenne would propagate a  
primary key value from the super-class table to the subclass table  
when inserting a new record (seeing as the next primary key value is  
a function of the parent table [or some other table that's keeping  
tabs]).

>>>> 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.

Sure, something like a Role-based mapping might be a good choice or  
whatever. Here's a bad example of a situation where the parent record  
may not want to be deleted along with the sub-entity.

Person -->> EmployeeRole
  ^
  |
  is-a -- Client

> 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.

I suspect we might be coming at this from different angles. I'm  
coming from the angle of modelling your object hierarchy to a schema  
(whether it exists or not) vs the other way around.

> 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.

By independently manage I assume you're talking about non-inheritance- 
based relationships which Cayenne fully supports ;-)

> 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.

Which is much appreciated. That's why this whole discussion began -  
so as to share ideas on this. I'm coming at this from an EOF heritage  
which has a certain mindset. Certainly Cayenne has its own (yet  
similar) approaches to these things and so such discussions are only  
helpful.

> 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.

Indeed.

with regards,
--

Lachlan Deck