[PEAK] peak DMs and model element component hierarchy

[Doug Quale]

"Phillip J. Eby" <pje at telecommunity.com> writes:

> At 10:04 PM 7/16/04 -0500, Doug Quale wrote:
> >Does it make sense to go to extra trouble in the DM to make the
> >parentComponent for a model element be the model element it is
> >included in, or is this pointless or harmful?
>
> Generally speaking, no.  The component hierarchy exists mainly to
> support acquisition of solution-domain configuration information.
> Model objects are part of the problem domain, not the solution domain.
> If a problem-domain object wants to take information about some other
> problem-domain object into account, this should be done explicitly.
> 
> IOW, the 'solution-domain' context of any 'problem-domain' object is its DM.

Thanks, that makes sense.

The specific situation I have been thinking about is a simple Postgres
database browser that I am playing around with refactoring to use some
parts of peak.

The original code used an Active Record approach with each model
object responsible for loading itself and its children.  I used a
simple-minded lazy attribute mechanism to delay loads of children to
avoid loading the thousands of objects in the entire database schema
when the top level node was created.  Each model object had a parent
reference.  The parent nodes were used to chain upwards
to get the database connection needed to load a nodes children.

Taking baby steps, I first tried using peak.binding to wire together
the tree-structured model of a database schema.  This is a very impure
use of peak.binding, but it was easy to refactor the existing code to
use the peak binding facility to handle parent attribute lookups and
lazy binding.  The parent attribute of greatest importance was the
database connection.  It's annoying to pass it everywhere it's needed,
but many different connections are required as described a little
below.)  The peak.binding code is much better designed and implemented
than my rather ad hoc code it replaced.

The "correct" peak facility to use to build the model is surely
peak.model.  Using peak.model, it makes sense to move away from Active
Record to use peak DMs to handle database queries and model object
creation.  The mental block I have run into is what to do with the
database connections.  Maybe they aren't really part of the domain
model, but the DMs need them to load the objects.  There isn't a
single static connection but multiple connections.  Within a single
database schema, different connections are needed at different levels.
Specifically, each Postgres cluster requires a different connection to
access the system catalogs that are shared by all databases in the
cluster.  Within each cluster multiple connections are needed at the
database level to access the system catalogs that are specific to each
database.

So, I'm not sure what to do with the connections.  I guess they are
part of a composite id for the model objects because the same database
names can be found on different servers, same table names in different
databases on the same server, etc.  The original code takes the
unclean approach of throwing everything into an Active Record.  Using
a more proper domain model and separate DMs is cleaner, but I don't
know how to manage the many connections that the DMs need.