Correct. "Abstract" and "lazy resolution" (and also various fetch/
instantiation strategies) are unrelated concepts.
Andrus
On Jun 4, 2007, at 3:19 AM, Lachlan Deck wrote:
On 04/06/2007, at 7:19 AM, Lachlan Deck wrote:
On 04/06/2007, at 6:40 AM, Lachlan Deck wrote:
On 03/06/2007, at 10:42 PM, Andrus Adamchik wrote:
2. Fetching only the base table on select should be possible, so
that's probably the most obvious benefit. Originally I thought
in this case users would always want to fetch the full objects,
and this buys us nothing, but from the earlier emails by
Lachlan, there may often be a need to iterate through just the
superclass attributes. Lazy fetching of subclass table may be a
better solution to that, compared to the one suggested before -
instantiating superclass objects, ignoring the correct class.
Hmm. That would be nice actually and would certainly simplify any
dealings with the global id. However, that may pose other
problems with PostLoad(?) whereby some code that you might
normally performed on PostLoad of a sub-entity may not be desired
to be run when just fetching the parent. How would you
discriminate between the two situations?
But taking a step back, if you're suggesting that the parent can
only ever be treated as abstract then the feature request for
isAbstract won't make sense anymore.
Woops. Disregard this statement. Momentary confusion of concepts ;-)
It wouldn't make sense to allow a parent to be abstract but yet
never actually be capable of being instantiated. For me, I think
this is a problem for the individual application to work out. By
having the discriminator column you've allowed the parent to be
instantiated whilst maintaining the correct global id haven't you?
Let me clarify that further by saying that I don't think it's
correct to allow the creation of parent entities and then later
morphing them into some sub-type. I'm only thinking of allowing
the instantiating of parent entities for the purposes of fetching/
performance considerations.
And further clarifying that again - of course it's perfectly okay
to create a persistent Person, for example, that is always a
concrete Person. That's where I think the discriminator column
comes into play when allowing the parent to be non-abstract...
with regards,
--
Lachlan Deck
