Re: [SQLObject] Re: Impressions so far

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

> True, however, if you're going to support schema generation, it makes
> sense to at least support the most common constraints: unique, not null,
> etc. As it stands, SQLObject nearly supports the common cases. Adding
> uniqueness support would allow SQLObject to support most common cases.

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. :)

Note that uniqueness is implied by "alternateID" as well, which is what
generates the byColName-type acccesses... maybe unique and alternateID should
become aliases? (only downside I can see is extra method creation overhead if
you don't actually care to access byName...)

> Speaking of enums, I notice that there's no explicit support for
> booleans. No big deal unless you consider schema generation, where the
> boolean column type should be generated.

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

> If I don't use a left outer join, I will get a list of people who have
> cars, and the people who don't have cars won't appear in it.
...
> How do I achieve the same as a left outer join without writing a loop?

Hmm. I see your example, and from an object dispatch perspective I'm not sure
how to solve it. I'm less interested from a performance viewpoint (it doesn't
matter to me immediately whether SQLObject actually uses LEFT/RIGHT join SQL),
but how I would specify this in python other than a Set (list) operation... I
suppose something explicit like Car.unionPerson / Person.unionCar could
work... ahh, there's the reason this doesn't fit into SO's model:

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.

> This raise the bigger question of how to handle connections when
> multiple modules, each implementing SQLObjects are used. What is the
> best way to do this?

Here's how we do it: Each group/registry defines a "CoreObject", an abstract
superclass for all actual objects that defines _connection. One place to
change it for an entire collection of objects.

> I have a global connection pool, so perhaps I should just have each
> SQLObject-based module import the pool and fetch a connection. Is this
> what the _connection attribute is for? Can we not use the DBConnection
> object?

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.

(Ian: thoughts on in a version or two renaming that to one of the other
possibilities like _dbDriver or ...?)

> Oh about orderBy... how do we specify whether it is ascending or descending?

You're the second (or third, if you count me :)) person who's asked this
recently.. not currently supported. It would need to be added to
SelectResults, and preferrably an addition to _defaultOrder would also be
made, although I didn't really like my initial naming _defaultOrderDirection,
but I can't think of a way to easily make it simply part of the _defaultOrder
var either (an optional tuple? urgh)..

Enough for now,

- Luke