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
This archive was generated by hypermail 2.0.0 : Fri Jun 01 2007 - 05:43:42 EDT