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.
Hi Craig,
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.
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?
Andrus
This archive was generated by hypermail 2.0.0 : Sun Jun 03 2007 - 08:43:20 EDT