Re: [SQLObject] thoughts on structure and components

[Bud P. B. <bu...@si...>]

I'm wondering, you may be right that my approach is more complex to
the end user??? Hmmm, not easy to say... so let me try to make a
concrete example that is similar to what you have in the doc:

#-- the application classes -------------

class Person(object):
  pass

class PhoneNumber(object):
  pass

# I like the fact that these are totally independent...

#-- making the above storable ------------------

personMap = ClassMap('Person', [
                     SimpleAttr('firstName', 'varchar', notNull=True, \
		                unique=True, length=100),
                     SimpleAttr('middleInitial', 'char', notNull=True, \
		                unique=True, length=1),
                     SimpleAttr('lastName', 'varchar', notNull=True, \
		                unique=True, length=100) ], \
	             tableName='perTab', idName='persid', autoSave=1)

phoneMap = ClassMap('PhoneNumber', [
                     SimpleAttr('phoneNumber', 'varchar', notNull=True, \
		                length=14),
                     SimpleAttr('phoneType', 'char', notNull=True, \
		                unique=True, length=1),
                     SimpleAttr('lastName', 'varchar',length=5) ],
		     autoSave=1)

# what I don't have yet are specialized Attr subclasses (such as you
# various Col subclasses.  These could probably save some typing and
# implement interesting semantics such as ENUM..

# also note that so far I don't deal with default values.  They belong
# in what I belive is the higher-level physical types that are
# application dependent.  I need to supply some base classes here to
# make life easy.  (Such as a nominal value class that is equiv to
# ENUM)

persPhoneRel = Many2Many(personMap, phoneMap, 'phoneNumbers')
appMap = Mapping([personMap, phoneMap], [persPhoneRel])

conn= psycopg.connect(...)
drv = PostgresPsycopgDriver()

backend = Backend(drv, conn, appMap)

#-------- and now everything is persistent ---------

So yes, this may be a little more verbose than SQLObject and I suppose
users are exposed to more classes.  There is some room for making it
more efficient for typing...  But in any case, I don't see a big
difference in complexity.  [Obviously, I'm biased on this...]


On 15 May 2003 10:52:26 -0500k
Ian Bicking <ia...@co...> wrote:

> 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)
> > \-----------------------------------------------------------------
> > 
> 
> 


/-----------------------------------------------------------------
| Bud P. Bruegger, Ph.D. 
| Sistema (www.sistema.it)
| Via U. Bassi, 54
| 58100 Grosseto, Italy
| +39-0564-411682 (voice and fax)
\-----------------------------------------------------------------