On 31/05/2007, at 11:46 PM, Craig L Russell wrote:
> Hi Ari,
>
> On May 31, 2007, at 12:21 AM, Aristedes Maniatis wrote:
>>
>> 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.
Well, normally the primary key attributes are not exposed in the
ObjEntity anyway, so I agree with what I think you are saying. But
the question here is about compound primary keys. If we want to be
able to support them as the basis for the join in vertical
inheritance, then we need an objRelationship explicitly defined.
>> 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, that might be the way you would want to do it, but why do we
want to limit what others might want to do? As an example, we have in
our current project two tables:
BinaryInfo
BinaryData
The info table contains metadata (creator, date, size, etc) and the
data table contains just the blob (pdf, image, etc). We wanted this
structure in separate tables so that:
* we could have different backup strategies for each
* we could optimise one table for big unindexed data
* we could put one table on a different db server, or whatever
At the moment, this is a one-one relationship, but inheritance would
be been much nicer. We would want both classes to be concrete so that
we could fetch binaryInfo over the network (say to display a list of
attachments) without fetching the BLOBs. We'd also like the ability
to 'delete' records by removing the binaryData completely and leaving
the binaryInfo record behind with a isDeleted flag for historical
auditing.
>
>> 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.
Sure. Although I haven't been thinking of it from a reverse
engineering perspective at all. That would be a useful extension.
> 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 Cayenne's implementation will be all the better for the extra
thinking your suggestions provoke.
> 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.
I agree. But at the same time, just because JPA/JDO people put a
limitation in the specification doesn't been we have to draw the line
there. We can always implement more functionality than is needed by
those specs. If JPA says that the superclass is always abstract and
we want to allow to make it concrete as an option, then more power to
our users.
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 - 20:06:34 EDT