Re: [SQLObject] thoughts on structure and components

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

Comments on at least a couple of your thoughts..

On Fri, 2003-05-09 at 04:28, Bud P.Bruegger wrote:
> > > Storable:
> > >   A superclass that makes application objects storable.  
> > >   It adds methods that interact with the Backend in order to
> > >   - store
> > >   - update
> > >   - delete
> > >   the object
> > >   In addition, it provided methods to easily access related objects
> > 
> > I can see how this might be stylistically different from the SQLObject
> > class, but how is it otherwise different?  (Well, there's SQLObject and
> > MetaSQLObject, but those are tightly coupled, and I think justifiably
> > so).
> 
> Maybe this is not at all different from SQLObject???  Can I write a
> class and then make what I call a storable application class that
> inherits from both the business-logic-only class and SQLObject?

Certainly.

> > SQLObject is tightly coupled to DBConnection (i.e., they chat a lot,
> > there's no well defined interface between the two, and information
> > that's available between the two of them isn't necessarily otherwise
> > public).  I can imagine them being decoupled, but only after SQLObject
> > had a long time to mature.
> 
> I believe that my thoughts kind of split up DBConnection into several
> different entities (connection, dbdriver, and maybe also backend?).
> This way, I can for example define what I call mappings before opening
> an actual connection to the dbms.  I see this as a sort of decoupling
> of components..

I would expect mappings to be the equivalent of your SQLObject
subclasses, which can be made independently of a database connection, or
can use a simple connection like DBM when you are first writing things
out.

> > But maybe you are really thinking of a super-superclass, i.e., something
> > that SQLObject would inherit from, as well as other significantly
> > different kinds of storage mechanisms.
> 
> I don't think so, but I don't understand the super-super concept
> well...

By that I mean that the SQLObject class, i.e., SQLObject inherits from
Storable, and perhaps something ZODB-like would also inherit from
Storable.  Storable would implement a common interface for certain kinds
of introspection necessary for persistence.

> > BConnection is something of a misnomer -- DBDriver would probably be a
> > better name (especially for the poorly named DBMConnection, which
> > doesn't connect to anything).  Well, in the beginning DBConnection was
> > really just a primitive form of connection pool, but that part is
> > relatively small now.  There's nothing particularly important about the
> > way they are joined.  If they weren't, though, the interface would look
> > pretty much the same (since the type of connection you make implies
> > which DBDriver you would use).  Separating DBConnection from DBDriver
> > isn't a very significant change, since they are naturally coupled.
> 
> I separated the two since it makes it possible to define mappings
> before having the connection in place.  Trying to devide and conquer,
> I tried to separate the creation of SQL (strings) and actually
> communicating with the dmbs..

Declaring a connection for a class is easy.  Why is it a problem?

Perhaps you're thinking of things like dbName, which map the Python
columns to a particular schema.  That's reasonable, but then if you are
mapping to a legacy database then you probably know that from the
beginning.

> > Right now you could hack something together to do this by using a Style
> > subclass that fed off a mapping table (instead of using algorithms to
> > map names).
> 
> This surprises me.  I see style and mapping as reasonably independent
> things.  Style just defines some defaults (such as converting names
> form case sensitive to case insensitive) and if I chose an appropriate
> style, it saves me some typing.  

A hacked Style could handle changes to your dbNames, that's about it. 
Though when I think of a mapping, that's a large part.

The other way would be to make a table-driven columnsFromSchema that was
attached to your connection, and let that create the columns for you.

  Ian