> "-1" for the implementation. I think it needs more thought.
>
> First of all I oppose DbEntity inheritance. This complicates any
> operations using the mapping. Even DerivedDbEntities that I introduced
> long time ago don't seem to be in the right place. This should all be
> done at the Obj level.
>
> Another concern is to avoid extra mapping artifacts if we can use
> generic ones. For instance there are other cases when we might want to
> join multiple entities, not just strictly "master-detail".
>
> So my suggestion is to implement this at the level of
> ObjEntity/ObjAttribute, with ObjAttribute being potentially "flattened"
> to span a few relationships (DbRelationships that is). This way we can
> do master-detail or any other kinds of complex mappings.
>
Sorry for being unclear, I do not mean any kind of DbEntity inheritance (how
can we do such a thing if DbEntity and table basically coincide anyway???).
Of course it should be done at the Obj level, and I tried to illustrate it
by the extract from data-map.dtd. Let me try to explain.
1) I need Cayenne to support inheritance of DataObjects (not DbEntities or
even ObjEntities) which means ability to add new persistent attributes to
subclasses of a persistent superclass.
2) In relational databases as opposite to OR databases there are two
principal ways to get the job done:
- Create new table for a subclass with old and new attributes totally
independent from the old one used by the superclass.It is a fast but
somewhat messy approach.
- Create a dependent table(s) (RDB term) to support new attributes. This
is a very neat and tidy way and also useful in some other cases (Craig gave
one quite important). Surely, it is slower, yet it has a great advantage
before the first approach - we always maintain the same and single identity
for all objects of the superclass and every subclass even as in the first
case the identities will be different becouse of the different primary keys
in each table.
3) Thus I want to try to implement the latter approach. All I need is to
have a way to say: CompoundDataObject relates to ObjEntity "CompoundEntity"
which in turn relates to primary DbEntity "MasterTable" and several
additional DbEntities "DependentTable1",.. "DependentTablen" and
ObjAttributes "attribute1",.. "attributem" map to such and such DbAttributes
belonging to DbEntities from the list.
4) In this case I needn't say anything about Db or Obj Relationships since
DbRelationships to "flatten" are already uniquely defined. Indeed, I know
that by definition for "MasterTable" and any "DependentTablei" I must
always choose the one-to-one relationship between their primary keys. For
"DependentTablei" it will be the primary key and foreign key at the same
time.
5) Then the semantics of operations IDENTIFY, INSERT, UPDATE, DELETE, SELECT
an object related to "CompoundEntity" is completely clear as identity of the
object relies exactly on "MasterTable", for "DependentTablei" it is simply
matter of synchronization, nothing more because "DependentTablei" does not
have identity by itself.
This is pretty much it. Although it would take some time to implement the
concept it is very clear and well grounded in itself.
I understand you suggest that we consider much more general case when
ObjAttributes "span a few relationships (DbRelationships that is)". It is an
appealing approach. SELECT and, maybe, UPDATE can probably be defined quite
decently for such objects, but how would you define INSERT and DELETE? How
would you define identity for such an entity if it spanned several tables
with independent primary keys? These questions remain obscure, must frankly
admit. Could you please give some more details?
Thanks.
Andriy.
This archive was generated by hypermail 2.0.0 : Fri Feb 28 2003 - 06:07:54 EST