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).
>
> What do you think?
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 - 01:05:51 EDT