Re: [CONF] Apache Cayenne Documentation: Inheritance overview (page created)

From: Andrus Adamchik (andru..bjectstyle.org)
Date: Mon Jun 04 2007 - 02:33:00 EDT

  • Next message: bob schellink (JIRA): "[JIRA] Created: (CAY-796) Deserialization of DataContext fails when useSharedCache is false"

    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