Andrei Adamchik wrote:
>
> 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.
>
We will need to navigate from the database table to the object entities when
processing the result sets, so there will be a need for the "backwards"
navigation
>
> B) Relationships & Joins
>
>
> 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).
>
Agree. I will rename the files shortly.
>
> C) Circular references between map objects
>
> 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.
>
Actually, the garbage collection was the last thing on my mind. I just thought,
that at the time of processing individual properties we don't need anything
else but the names of the object entity (or database table in case of db
layer), so we could get by without references. As for the references between
the db attributes and obj attributes... yes, we need the type information in
addition to the name, so you are right, we will need the links there.
> 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