On Jun 1, 2007, at 2:42 AM, Andrus Adamchik wrote:


On May 31, 2007, at 9:51 AM, Lachlan Deck wrote:

There are numerous uses for these partial instances (if you'd like to call them that) when you want to only fetch the characteristics of the parent, for example, without also having to fault in the data for the subclasses. e.g., if I have a service thread that once every 10 minutes or so polls a message-queue to send a message to a list of recipients the only data I'm interested in fetching in is that of the parent entity.

I still have trouble with this. If this is a requirement, I'd suggest mapping the superclass independently, that is using a completely different class. Then you can have part of your application that doesn't care about the subclass part at all.

It would still be a very bad choice if you were to mix the model containing the full inheritance relationship and the partial mapping, because you would potentially have conflicting updates of the same data. But you would be avoiding the complexity and the usability issues associated with having an instance that was mapped as a subclass yet in memory had no subclass behavior.

Craig


This is not breaking any inheritance rules even in Java as I see it. It is after all possible in Java itself to have a non-abstract superclass. Whether this leads to a broken mapping or otherwise I don't believe should be a restriction enforced by the tool... but certainly you might like to document the advantages/disadvantages of such an approach.

Hmm... Thinking about it from different angles, I tend to agree with Lachlan. A user can bend the rules with a shallow fetch on a non-abstract superclass, as long as (s)he understands that this (a) breaks uniquing and (b) deleting or inserting such records is asking for trouble.

Still IMO, this is not related to the delete rule discussion. An implied CASCADE is the right thing.

Andrus


Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to