Re: [SQLObject] Re: Impressions so far

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

On Sat, 2003-05-31 at 21:47, Luke Opperman wrote:
> > 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...)

Yeah, maybe the two are rather redundant.  I wouldn't worry about the
method creation overhead, but more about having useless methods laying
around.

Maybe alternateID should be removed, and unique would imply
alternateID.  alternateMethodName would become fetchMethodName, and it
would be required if you wanted what is now byColName.

> > 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?

Exactly -- all the fancy SELECT statements create results that aren't a
homogeneous list of database objects.  *Some* statements could be turned
into a list of tuples or dictionaries of database objects, like [(p,
p.car) for p in Person.select()] -- and maybe being able to product that
same sort of result from a single SQL query would be useful in SQLObject
(though a lot of work to implement, and usually not necessary)...

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

Ah... SiteSQLObject ;)  SitePage annoys me sometimes, though... should
there be a better way to do this?

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

I want to rename all the *Connection classes to be *Store, after this
next release.  Then _connection becomes _store, or maybe __store__.  Is
that the renaming you are thinking about?

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

SQLBuilder could handle it with just a simple (but not yet existent)
function, but most people aren't using SQLBuilder for orderBy (like
Person.select(orderBy=(Person.q.lname, Person.q.fname)).

I'll add an option to SelectResults, probably "descending", that will do
this.

  Ian