Correct. "Abstract" and "lazy resolution" (and also various fetch/
instantiation strategies) are unrelated concepts.
Andrus
On Jun 4, 2007, at 3:19 AM, Lachlan Deck wrote:
> 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 : Mon Jun 04 2007 - 02:33:23 EDT