Re: [SQLObject] Re: Impressions so far

[Edmund L. <el...@in...>]

Luke Opperman wrote:

> Actually, notNull and unique are both currently supported by columns. Ian's a
> good documenter, there's just been a lot of changes since the last cut. :)

I stumbled across the unique option about the same time as you were 
emailing me!

A suggestion: remove the notNull option, and force people to use 
notNone. The former is really a SQL thing, and the latter a Python 
thing. On the theory that people who use ORMs don't want to know about 
SQL, having notNull is a bit unnecessary.


> Yep. Big problem holding this back is that any current implementation of a
> BooleanCol doesn't work in Postgres, because saying "obj.boolCol = True" fails
> during SQL conversion, since PG won't accept integer literals for boolean
> values. Grr.. (I'm a happy PG user, but this always bothers me...)

Do a behind-the-scenes conversion to the strings "1" and "0" or "t" and 
"f". This way, boolean support in DBs that don't have booleans (e.g., 
Oracle) is easier.


> It specifies results that are neither Cars nor Persons. How would you propose
> to represent the return values from such a function as objects?
> 
> I think in the O-R world there is no way to do this without loops or Set
> operations. But I'd happily be proven wrong.

I see the problem. And yet, this is such a common thing to want to do... 
Hmmm... returning a list would be best, but these certainly aren't 
schema-derived objects... Hmmmm...


> We use a global pool too, so we have a simple subclass of PostgresConnection
> that imports the pool and overrides getConnection (return
> globalPool.getConnection()), releaseConnection (conn.close()), and
> makeConnection (a no-op). _connection (and DBConnection etc) have a confusing
> name, as they define a lot more than just the connection... they also do all
> the SQL access generation, so you can't just set it to your current pool's
> connections.

Hmmm... so if multiple SQLObject modules are imported, will they all use 
the same global pool? What if they have differentt connection strings?

Nuts, I guess I'll have to take a closer look at the DB connection 
code... I just want a single place to specify the connection string for 
all modules, and have them use the same pool.


BTW, I'm really banging away at SQLObject, and had to rewrite my data 
model to suit it. However, layering SQLObj on to it has been quite 
painless, and it does seem to be very pleasant to use. Being able to 
control the names of the underlying columns and tables is _really_ critical.

...Edmund.