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

From: Lachlan Deck (lachlan.dec..mail.com)
Date: Sun Jun 03 2007 - 17:19:10 EDT

  • Next message: Lachlan Deck: "Re: [CONF] Apache Cayenne Documentation: Inheritance overview (page created)"

    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