Re: Abstract Entities [Was: Modelling improvements: inheritance + interfacing (Draft)]

From: Lachlan Deck (lachlan.dec..mail.com)
Date: Fri Jun 01 2007 - 09:54:24 EDT

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

    Hi there,

    On 01/06/2007, at 10:50 PM, Craig L Russell wrote:

    > On Jun 1, 2007, at 2:42 AM, Andrus Adamchik wrote:
    >
    >> On May 31, 2007, at 9:51 AM, Lachlan Deck wrote:
    >>
    >>> There are numerous uses for these partial instances (if you'd
    >>> like to call them that) when you want to only fetch the
    >>> characteristics of the parent, for example, without also having
    >>> to fault in the data for the subclasses. e.g., if I have a
    >>> service thread that once every 10 minutes or so polls a message-
    >>> queue to send a message to a list of recipients the only data I'm
    >>> interested in fetching in is that of the parent entity.
    >
    > I still have trouble with this. If this is a requirement, I'd
    > suggest mapping the superclass independently, that is using a
    > completely different class.

    The question in the end is whether the tool/framework enforces what
    in the end (as it seems to me) comes down to an object design
    decision of which there are always various forks in the road as it
    can depend on the needs of the individual application (which we all
    know in reality can change/grow at any particular point in time
    throughout the life of an application). e.g., such design decisions
    cannot always be imposed upon legacy systems.

    I'm simply suggesting that Cayenne (and any other ORM for that
    matter) can quite simply allow for either case. To do so is at the
    end-user's risk.

    > Then you can have part of your application that doesn't care about
    > the subclass part at all.

    That certainly is a risk that is worth documenting for an end-
    developer but I don't believe should be enforced by the framework. In
    most situations (that I can envisage anyway) the use-case for
    instantiating a parent entity (rather than the sub-entity to which it
    belongs) would be in a read-only mode. But again that's application
    specific.

    > It would still be a very bad choice if you were to mix the model
    > containing the full inheritance relationship and the partial
    > mapping, because you would potentially have conflicting updates of
    > the same data.

    I'm not sure how that would be different from current update
    conflicts. Perhaps that would depend upon the locking behaviour
    (optimistic etc).

    > But you would be avoiding the complexity and the usability issues
    > associated with having an instance that was mapped as a subclass
    > yet in memory had no subclass behavior.

    Are there any particular complexities you have in mind?

    For mine, any such complexity would be introduced by an individual
    developer, I believe, in edge-cases where for some strange reason the
    developer decides to modify the parent record (e.g., incrementing
    some dateOfLastAccess field).

    I suppose I keep coming back to this question: 'why should the
    framework impose an ideal restriction when there are in reality
    business cases for doing otherwise?' i.e., If allowing the parent
    record to be fetched on its own without needing to additionally fetch
    the sub-type characteristics allows for certain performance benefits,
    for example, or otherwise then for mine: +1. Some other developer may
    have some other needs for which these flexibilities finds a home. All
    in all my persuasion is that best-practices (for hazy areas like
    this) are best aimed at documentatation/white-papers.

    The only complexity I can envision (at this stage - perhaps Andrus
    would have a better idea) is dealing with the global ids for two
    objects in memory that for all intents and purpose are the same
    object, each of which are in separate contexts but where one was
    fetched as the superclass rather than the subclass it was originally
    created as. But other than that the normal rules would apply - i.e.,
    where the mapped entity that the parent object corresponds to is the
    parent entity that just happens to also have a sub-entity. I'm not
    certain at this stage how the object graph would track these. But it
    doesn't seem to be something that's conceptually difficult.

    >>> This is not breaking any inheritance rules even in Java as I see
    >>> it. It is after all possible in Java itself to have a non-
    >>> abstract superclass. Whether this leads to a broken mapping or
    >>> otherwise I don't believe should be a restriction enforced by the
    >>> tool... but certainly you might like to document the advantages/
    >>> disadvantages of such an approach.
    >>
    >> Hmm... Thinking about it from different angles, I tend to agree
    >> with Lachlan. A user can bend the rules with a shallow fetch on a
    >> non-abstract superclass, as long as (s)he understands that this
    >> (a) breaks uniquing and (b) deleting or inserting such records is
    >> asking for trouble.
    >>
    >> Still IMO, this is not related to the delete rule discussion. An
    >> implied CASCADE is the right thing.
    >>
    >> Andrus

    with regards,

    --
    

    Lachlan Deck



    This archive was generated by hypermail 2.0.0 : Fri Jun 01 2007 - 09:54:55 EDT