On 04/06/2007, at 6:40 AM, Lachlan Deck wrote:
On 03/06/2007, at 10:42 PM, Andrus Adamchik wrote:
On Jun 3, 2007, at 2:44 PM, Craig L Russell wrote:
I am still entertaining the idea that we can support vertical
inheritance without a designator column, and I don't think that
having such column in place is such a big shortcut in
implementation. After all the logic will be the same as with
horizontal inheritance - sublcass criteria is an existence of a
row in the subclass table).
The big win here is in performance. If you don't need the
subclass values but need to know the subclass, then the
discriminator allows you to instantiate the right class without a
join.
I omitted performance considerations from my previous email, as I
wanted to do some analysis of specific cases first. I can think of
two typical cases where this may apply:
1. Inferring the object class of a target of to-one relationship
to a superclass will NOT be possible just by looking at FK, unless
a discriminator column is also a part of the target PK (and source
FK). So no DB trip savings in resolving relationships.
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. 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.
So... considering item #2, we need to give user the flexibility to
do lazy vs. eager fetch of multi-table inheritance hierarchies.
Wonder if overriding "setResolvingInheritance" flag to handle this
is appropriate, or we should handle it as another case of
"prefetching a relationship", only this time a DbRelationship that
defines the inheritance?
Yes, but my thinking on this was that the determinant for resolving
inheritance would depend on isAbstract but if isAbstract was to go
away, how would this work?
with regards,
--
Lachlan Deck
