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?
> 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
This archive was generated by hypermail 2.0.0 : Sun Jun 03 2007 - 16:40:51 EDT