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 BinaryDataThe 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 whateverAt 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
PGP.sig
Description: This is a digitally signed message part
