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
