[SQLObject] Metadata container

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

There's a bunch of metadata right now that is being stored in various 
instance variables, all ad hoc like, and with no introspective 
interfaces.  I'd like to consolidate these into a single object/class 
that is separated from the SQLObject class.  This way I don't have to 
worry about name clashes, and I don't feel like every added little 
interface will be polluting people's classes.  (Though most of the 
public methods that are there now will remain methods of the SQLObject 
subclasses, just like they are now)  So I'm looking for feedback on how 
that should work.

There's actually two kinds of metadata -- the metadata for the class, 
like a list of columns, and the metadata for the instance.  There's not 
a lot of instance metadata at this point, but it would include things 
like if the object was dirty, or obsolete (deleted), etc.  There's also 
a bunch of internal bookkeeping-style attributes that SQLObject uses 
which are on a per-instance level.

So... how should these look?  I've been thinking of something like:

SQLObject.sqlmeta.columns: dictionary of columns
.table: DB-name of table
.store: the DBConnection object (kind of)
.cacheColumns: true if we cache columns (vs. fetching them on each 
access)
.obsolete: true if the object has been deleted (but not garbage 
collected yet)

and so on.  In turn column objects will have a better public interface 
as well, so you can look at the particulars of a column.

But it's a little confusing, because some of these belong to the class 
and some to the instance.  This is fine now, because some are class 
variables and some are instance variables, and instances get all the 
class methods, but can also shadow them and other stuff (though that's 
used only in small ways).

We could do that now if SQLObject.sqlmeta was a class, and 
aSQLObjectInstance.sqlmeta was an instance of that class... but is that 
weird or confusing?  Should it be SQLObject.SQLMeta and 
aSQLObjectInstance.sqlmeta?  That doesn't seem much better.

I'm also thinking that you will subclass this metadata class to add 
many options, but again that could seem weird.  E.g.:

class Contact(SQLObject):
     class sqlmeta(SQLObject.sqlmeta):
         table = 'contact_table'
         cacheInstances = False
     name = StringCol()
     ...

Column objects also become descriptors, and so are part of the class 
directly -- in the end it's less funny metaclass stuff, but they will 
probably call on this sqlmeta object to do most of the work.

I'm thinking that this could clean up the code a great deal, but I'm 
still not entirely sure how this should look, so I'm looking for 
feedback.

--
Ian Bicking | ia...@co... | http://blog.ianbicking.org