>I have checked in some Data map related classes for:
Cool, we are finally producing some code...
>Also, please take a look at the updated model and let me know you
>comments. There had been several assumptions made:
>1. The Object entity (metadata for the data object class) must
>correspond to some database table (DbEntity)
>2. Some DbEntities will have no ObjEntities associated with them.
>3. All attributes of the ObjEntities are mapped to the same table.
A) ObjEntity-DbEntity relationship:
Why do we need to have objectEntity pointer in DbEntity? (DbAttribute -
ObjAttribute has the same problem). I guess it makes sense to use layered
design, where bottom layer (Db* classes) is not aware of the layers built
on top (Obj* classes), while top layer can access everything underneath it.
Do you see any reason to access ObjEntity, etc. from DbEntity ? I don't.
B) Relationships & Joins
>Thus we don't have the relationship on the level of the attributes, but
>only on the level of the entities.
This is the way it is supposed to be. Also remember we discussed meaning
of the term Join. Class DbAttribute pair seems like a Join to me
(combination of PK-FK). So if this becomes a *join*, I suggest to rename
present join definition to something like DbRelationship as opposed to
ObjRelationship (I wonder if we should stick to a naming convention for all
map classes: Obj* and Db* to separate the layers). (it describes connection
between 2 tables , so potentially it can be used to traverse many-to-many
relationships across a join table, right?)
So now DbRelationship always describes simple connection between 2 tables,
while ObjRelationship will describe connection between 2 entities,
potentially crossing multiple tables. So ObjRelationship will consist of 1
or more DbRelationship(s).
C) Circular references between map objects
>Also, attributes don't need to have
>the reference to the entities, but only string variables storing the
>name of the table/dataobject class.
Maybe this is not a big problem (circular references in the map), I think
we can do it either way, whatever is more convenient. It may slow down
garbage collector, but it should still figure it out. Besides, in 90% of
cases scope of map objects will be == to application lifetime, so garbage
collection is not an issue... It is much more important to implement
relationships between actual data objects to avoid this. Here all those
Java "weak references" will come to play.
So I wonder if we can replace strings with pointers to real objects for
performance within Obj* and Db* layers, and just leave links from Obj*
layer to Db* layer, but no link back to Obj*? This seems simpler to
implement and work with. If you keep them as strings, you will need to
maintain a pointer to some map context object (say DataMap), accessible
from anywhere, and then do a tree lookup to find anything at all. This
seems like a lot of trouble.
>Please let me know the scenarios when this doesn't work out. If I don't
>hear any criticism until Saturday, I plan to start working on the XML
>representation of this schema and loading stuff from the database
>metadata.
>
>Misha
D) XML format and ways to load it...
Cool, BTW I already have some format for DataDomain XML file. Take a look
at ObjectStyle/cayenne/doc/datadomainsample.xml . Also I wrote a generic
resource locator (org.objectstyle.cayenne.access.XmlConfigReader) , think
we should pull it out of "access" package, since it can be used to load any
xml files using different protocols, and hopefully this will work with app
servers.
I suggest we use it for map loading as well....
Andrei
This archive was generated by hypermail 2b30 : Sat Aug 04 2001 - 16:21:24 EDT