Re: [SQLObject] thoughts on structure and components

[Ian B. <ia...@co...>]

Just looking at your example below, doesn't this seem like a lot more
work than SQLObject?  What was two classes (Person and PhoneNumber),
becomes seven (Person, PhoneNumber, StorablePerson, StorablePhoneNumber,
a Person mapper, a PhoneNumber mapper, and a relation).

I like that SQLObject's UML diagram (which doesn't exist, but let us
imagine it) is a boring diagram, and that each class you use requires
one class definition.

On Tue, 2003-05-13 at 02:15, Bud P.Bruegger wrote:
> So assume your app has a class Person, a class PhoneNumber, and a
> 1:many relationship between them.  So there would be the following
> steps to make this storable:
> 
> * make StorablePerson and StorablePhoneNumber with multiple
>   inheritance from Person and Storable, and PhoneNumber and Storable,
>   respectively.  This would add methods to communicate with the
>   backend.  Not sure yet, how I will do this--but hope to have some
>   initial code in a couple of days.
> 
> * make a mapping objects that contains (aggregation) three major
>   subobjects:
>   - an ObjMap that basically represents the Person table
>   - an ObjMap that represents the PhoneNumber table
>   - a relationship object that defines the relationship between them
>   So a mapping has a set of "table definitions" and a set of
>   relationship definitions.  "TableDefinitions" consist of a set of
>   attributes and attributes of a set of columns (in most cases just
>   one).
> 
> * create a backend object by assembling a dbDriver, a dbConnection,
>   and the above mapping object.  The dbDriver takes information
>   expressed in terms of mapping entities to create SQL statements
>   (strings).  The connection sends these off...  The backend object
>   manages all this.  
> 
> * storablePerson and storablePhoenNumber objects know about the
>   backend object and ask it to be stored, updated, deleted.  The
>   backend first checks the class of the object and uses it to find the
>   according mapping (name match).  Mapping and Driver produce the SQL
>   with variables for values, as well as marshal the python values of
>   the object for use in sql statments.
> 
> * backend also provides finder methods that basically correspond to
>   select queries..
> 
> * backend shoudl also manage a cache and do some concurrancy
>   control...
> 
> Hope this clarifies my ideas a little.
> 
> best cheers
> --b
> 
> 
> On 12 May 2003 17:10:40 -0500
> Ian Bicking <ia...@co...> wrote:
> 
> > On Mon, 2003-05-12 at 10:39, Bud P.Bruegger wrote:
> > > > Now, if I'm reading it right, this would be the most significant
> > > > difference with SQLObject -- a mapping object is a separate from the
> > > > class.  But why?  
> > > 
> > > Ian, I made some progress and I can more clearly answer to the
> > > question above:
> > > 
> > > In this approach, relationships are instances managed by Mapping, not
> > > part of the "class" (of the storable application object).  This way,
> > > to keep object references from the relationship object to the
> > > contained (from, to..) "table objects" (that I call ObjMap).  I can
> > > also keep back-references from ObjMap to all the relations that
> > > reference it.  
> > > 
> > > This way, I avoid (at least it seems at the moment) all problems of
> > > circular dependencies, referencing to objects only by name, etc.  
> > 
> > I'm still not really clear what you're thinking.  Can you show how you
> > might define a class, using a mapping?
> > 
> >   Ian
> > 
> > 
> > 
> 
> 
> /-----------------------------------------------------------------
> | Bud P. Bruegger, Ph.D. 
> | Sistema (www.sistema.it)
> | Via U. Bassi, 54
> | 58100 Grosseto, Italy
> | +39-0564-411682 (voice and fax)
> \-----------------------------------------------------------------
>