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