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

From: Craig L Russell (Craig.Russel..un.COM)
Date: Fri Jun 01 2007 - 08:50:58 EDT

  • Next message: Lachlan Deck: "Re: Abstract Entities [Was: Modelling improvements: inheritance + interfacing (Draft)]"

    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. Then you can have part of your application that
    doesn't care about the subclass part at all.

    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. 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.

    Craig

    >>
    >> 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
    >

    Craig Russell
    Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
    408 276-5638 mailto:Craig.Russel..un.com
    P.S. A good JDO? O, Gasp!





    This archive was generated by hypermail 2.0.0 : Fri Jun 01 2007 - 08:51:31 EDT