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
This archive was generated by hypermail 2.0.0 : Sun Jun 03 2007 - 17:19:39 EDT