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
This archive was generated by hypermail 2.0.0 : Sun Jun 03 2007 - 20:29:43 EDT