Andriy Shapochka wrote:
> 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.
Cool, then we are on the same page about that. Sorry for
misunderstanding. All I have is a lame excuse of doing 4 projects
simultaneously and being wasted all the time as a result :-).
> 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.
- And there is another one discussed in the link I sent: have one big
table with all attributes, and do entity inheritance, with superclass
only mapped to a subset of columns, while each subclass can map any of
the remaining columns. This is actually pretty cool for improving O/R
performance, though wastes some extra space (very little indeed).
>
> 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.
>
> 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?
I guess you are right about INSERT and DELETE, though SELECT is pretty
important. For instance I am doing this stats application (nhl.com) that
has tons of statistics tables that have "to one" relationships to tables
that are not "detail" and do not generally depend on the "master". For
instance each stats record can have "many-to-one" to "player" and "game"
records. They are read only and can be mapped as one big entity (though
prefetching works OK too).
So like I said to avoid extra mapping artifacts, we can map "flattened"
ObjAttributes via underlying DbRelationships (I guess only "to-one"
will qualify). Internally we will check if entities with such attributes
are "read-only" or "read-write". You outlined the rules for this check
above.
So basically instead of "dependent-db-entity" in
<!ELEMENT obj-entity (dependent-db-entity*, obj-attribute+)>
I suggest to use:
<!ATTLIST obj-attribute
name CDATA #REQUIRED
db-attribute-path CDATA #REQUIRED
type CDATA #REQUIRED
>
(I hate DTD :-))
"db-attribute-path" instead of being just a name of DbAttribute will be
a path to destination DbAttribute via relationships (just like the path
we use in expressions).
Am I making sense?
Andrus
This archive was generated by hypermail 2.0.0 : Fri Feb 28 2003 - 22:49:03 EST