Re: [SQLObject] Releasing 0.4

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

On Thu, 2003-05-22 at 10:07, Luke Opperman wrote:
> Ian et al -
> 
> Following on Mohan's problems with 0.3, and restarting a thread from a few
> weeks ago, what do you have in mind before releasing 0.4. Haven't seen any
> major CVS updates since I submitted the transaction implementation, and we're
> using CVS+MemoryTransaction+MultiRegistry+odds&ends in a couple apps about to
> go live here. So at least for my use cases, CVS has not revealed any bugs in
> the last week or two. How about an 0.4b after the holiday weekend?

The other big thing that's been holding me up is that I'd like to rework
the documentation.  Actually, I have to, since there's a number of
stylistic things that have also changed.  Documentation... sigh...

> Here's my list of maintained changes against CVS, just for the record (and if
> anyone thinks they should go in for a new release...):
> 
> * Multiple classRegistry's, via optional class-level "_registry" string.

Okay, this has been committed.

> * Converting _defaultOrder to dbcolumn via column lookup if it's in
> python-style. (Select orderBy expects db-style, but it makes more sense to me
> to specify in python-style.)

Okay.  I implemented it differently than you, you might want to check it
in CVS.  (It's implemented in SelectResults)

> * Use of _defaultOrder in Joins performJoin(), for now a naive python sort.

Yes, but you should be able to turn it off as well.  I added an orderBy
argument to joins, where None means no ordering, unspecified means pick
it up from the appropriate class.

> * Minor changes in new (setting inst._connection if passed in), and joins
> (using inst's _connection) that make logical sense, and allow
> MemoryTransaction to work.

I think this is already correct.  The connection gets passed from new to
__new__, then from __new__ to _init, and in _init it gets set.

> * SQLObject.copyToConnection()

I think your implementation only does something for the particular case
of MemoryTransaction -- it doesn't do a general copy between
connections.  Maybe it could go in, but undocumented and with a warning
comment.

> * aliasing of destroy to destroySelf for backwards compatibility until destroy
> is meaningful..

I don't think destroy will ever be meaningful.  I'm still thinking of
getting rid of destroySelf in lieu of the delete class method.

> * A few miscellaneous columns. Most important, BooleanCol. (However, BooleanCol
> doesn't actually work properly with Postgres, as Postgres refuses to accept
> integers for BOOL fields; it's a long story. Need to implement toSQL/toPython
> Column functionality to fix this. But that's probably for 0.5 :)

Yeah, I know, it sucks.  Right now I'll just document using the sqlType
argument to Col, and how to create the right _set_ method for a boolean
column.  BooleanCol can go in properly when it works without hacks.

> * MemoryTransaction, although I'd understand if this were left out of this
> release. :) Related note: I need to write some docs on MemoryTransaction
> still.

Yes, docs are important.  Given those it can go in, marked experimental
for now.

  Ian