Re: [SQLObject] alternateMethodName and creating SQL

[Luke O. <lu...@me...>]

Quoting Ian Bicking <ia...@co...>:

> It's a little fuzzy.  Some exception will be raised if nothing is
> returned.  Ambiguous results are silently ignored right now, which
> probably isn't good.  Ideally you should declare the column UNIQUE in
> your table schema.  If SQLObject ever generates table schemas (maybe not
> far off) then it would add UNIQUE based on this, but would otherwise let
> the database do the work of ensuring that.

Yes, generating schemas was the second part of my subject that I now realize I
never wrote. :) I haven't quite decided how to handle varying databases, but
that's not an issue for me at this moment.

How we're generating SQL is by subclassing Col, so our object defs look like:

class OurObj(SQLObject):
  _columns = [
      String('name'),
      Integer('toes'),
      Date('birthday')
      ]

and SQLObject has a classmethod "createSql", which calls out to each column's
own createSql method, taking into consideration foreignKeys and alternateIds.
RelatedJoins are still biting us, but mostly because I haven't looked at it enough.

I suppose one solution to the database-variance would be to have modules for
each Column-subclass group (String,Int,Float,Date,whatever) so you'd

from PostgresTypes import *
or
from MySqlTypes import *

and those would be responsible for defining the createSql method.

We're also using the Column subclasses to enforce validation, which means our
base Column has a validators=[] named parameter, and String's __init__ adds a
default AsString() validator to the start of that list etc. We're using the same
ValidatorConverters we have from working with FFK, btw.

That's all I've got to write tonight.

- Luke