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

From: Lachlan Deck (lachlan.dec..mail.com)
Date: Wed May 30 2007 - 16:13:25 EDT

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

    On 30/05/2007, at 3:04 PM, Lachlan Deck wrote:

    > On 29/05/2007, at 11:02 PM, Andrus Adamchik wrote:
    >
    >> Ok, I overlooked the issue of DB mapping of abstract entities that
    >> do not have a DbEntity. IIRC this issue was raised when we
    >> discussed embeddables. Not sure we came to any conclusion back
    >> then. So is this what proposed "DbEntity interfaces" are for?
    >
    > I'm not familiar with the embeddable discussion but this is the
    > idea of DbEntity interfaces:
    > a) you have a series of DbEntities that are not inherited in any
    > way but for which you want them to conform to an interface 'A'.
    > They are explicitly tied to that interface (rather than having to
    > synchronise to it). i.e., the attributes/relations appear as they
    > do for inherited characteristics. i.e., they're defined once per
    > model and implemented by various other DbEntities.
    >
    > b) an ObjEntity interface 'a' may optionally map to a DbEntity
    > interface 'b'. Any ObjEntity 'c' that maps to a DbEntity that
    > implements 'b' will be shown to implicitly implement the associated
    > ObjEntity 'a'.
    >
    > c) then there are the ObjEntity interfaces that have no associated
    > DbEntity interface...
    >
    >> Maybe we can simplify that and continue mapping abstract
    >> attributes (be for abstract ObjEntities or Embeddables) by simply
    >> specifying a "db attribute name", allowing to override it in a
    >> concrete definition? This is very close to how JPA suggests to do
    >> it, would cut down on the separate interface definitions, and
    >> allow to reuse the existing XML format without change (except for
    >> "isAbstract" flag).

    On further reflection, isn't that concept similar to the EOF's EO
    [Adaptor]Prototypes? i.e., defining abstract attributes (e.g.,
    nameField_varchar(64)) that can be utilised by various non-abstract
    attributes in any DbEntity.

    The concept I'm suggesting, however, allows a protocol to be defined
    that a DbEntity adheres to rather than an individual attribute. Such
    protocols, of course, can, via inheritance, be the combination of a
    few interfaces.

    > Sounds like a supporting concept. i.e., an interface provides for a
    > specification that includes attributes x, y, & z with certain
    > constraints.
    >
    > An abstract attribute on its own would be useful within an interface.

    with regards,

    --
    

    Lachlan Deck



    This archive was generated by hypermail 2.0.0 : Wed May 30 2007 - 16:14:11 EDT