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