sqlobject-discuss

[SQLObject] Looking towards 0.5

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

To start a separate thread, I'd like to open up discussion for what new things
people are working on or considering for 0.5 (since 0.4 will be mostly a
maintenance release, as I count it new features are just improved createSQL
stuff and changes to Col to allow SQLObject inheritance to work properly.)

My thoughts for post-0.4:

* MemoryTransaction or an equivalent.

* Some decision on concurrency control/resolution (should SQLObject offer any,
and if so then let's do it.)

* Actual enforcement of a constraints/validators system, at least providing
toSQL/toPython functionality. (Ian, I know you've been busy on FormEncode, and
that will be a help here :)

That's all I've got for now.

- Luke

Re: [SQLObject] Looking towards 0.5

[Brad B. <br...@bb...>]

On 05/22/03 10:18, Luke Opperman wrote:
> To start a separate thread, I'd like to open up discussion for what new things
> people are working on or considering for 0.5 (since 0.4 will be mostly a
> maintenance release, as I count it new features are just improved createSQL
> stuff and changes to Col to allow SQLObject inheritance to work properly.)
> 
> My thoughts for post-0.4:
> 
> * MemoryTransaction or an equivalent.
> 
> * Some decision on concurrency control/resolution (should SQLObject offer any,
> and if so then let's do it.)
> 
> * Actual enforcement of a constraints/validators system, at least providing
> toSQL/toPython functionality. (Ian, I know you've been busy on FormEncode, and
> that will be a help here :)
> 
> That's all I've got for now.

The framework needs a solid test suite. I can see there are some bugs
that have crept into SQLObject that would probably never have been
there in the first place with test-driven development (e.g. dropTable
not dropping sequences for PostgreSQL backends).

I've been insanely busy with work and talks in the past few weeks
(spent six hours on the road last night going to and returning from
giving a talk to the Brandon Unix User group!), am moving to Quebec
City on May 30, and have to prepare for the EuroPython talk late next
month about SQLObject.

But I'm definitely interested in retrofitting a test suite onto the
framework (basically by writing unit tests against the documented API)
and hope that future SQLObject contributions will submit unit tests
with their code.

-- 
Brad Bollenbach
BBnet.ca

Re: [SQLObject] Looking towards 0.5

[Brad B. <br...@bb...>]

On 05/22/03 11:04, Brad Bollenbach wrote:
> On 05/22/03 10:18, Luke Opperman wrote:
> > To start a separate thread, I'd like to open up discussion for what new things
> > people are working on or considering for 0.5 (since 0.4 will be mostly a
> > maintenance release, as I count it new features are just improved createSQL
> > stuff and changes to Col to allow SQLObject inheritance to work properly.)
> > 
> > My thoughts for post-0.4:
> > 
> > * MemoryTransaction or an equivalent.
> > 
> > * Some decision on concurrency control/resolution (should SQLObject offer any,
> > and if so then let's do it.)
> > 
> > * Actual enforcement of a constraints/validators system, at least providing
> > toSQL/toPython functionality. (Ian, I know you've been busy on FormEncode, and
> > that will be a help here :)
> > 
> > That's all I've got for now.
> 
> The framework needs a solid test suite. I can see there are some bugs
> that have crept into SQLObject that would probably never have been
> there in the first place with test-driven development (e.g. dropTable
> not dropping sequences for PostgreSQL backends).
> 
> I've been insanely busy with work and talks in the past few weeks
> (spent six hours on the road last night going to and returning from
> giving a talk to the Brandon Unix User group!), am moving to Quebec
> City on May 30, and have to prepare for the EuroPython talk late next
> month about SQLObject.
> 
> But I'm definitely interested in retrofitting a test suite onto the
> framework (basically by writing unit tests against the documented API)
> and hope that future SQLObject contributions will submit unit tests
> with their code.

Just updated from CVS, and I can see that tests/test.py is
growing. Cool. :)

-- 
Brad Bollenbach
BBnet.ca

Re: [SQLObject] Looking towards 0.5

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

On Thu, 2003-05-22 at 10:18, Luke Opperman wrote:
> My thoughts for post-0.4:
> 
> * MemoryTransaction or an equivalent.

Sure.

> * Some decision on concurrency control/resolution (should SQLObject offer any,
> and if so then let's do it.)

If we can come to decisions ;)  And implementations, of course.

> * Actual enforcement of a constraints/validators system, at least providing
> toSQL/toPython functionality. (Ian, I know you've been busy on FormEncode, and
> that will be a help here :)

Yes, that's distracted me from SQLObject stuff recently.


I'd also like to do some cleanup of names:

sqlRepr -> __sqlrepr__
*Connection -> *Store
Maybe others.  _columns -> __columns__ ?
I don't like the _setting style, but maybe lots of __setting__ names
just get excessive, and they shouldn't be public (i.e., no
underscores).  The old names would still work for a version or two, with
warnings being printed maybe in 0.6.  sqlRepr might be more quickly
deprecated, but none of the others.

The constraints/conversion stuff is getting closer.  I want to do one
more renaming on Validator, and change the class hierarchy slightly (so
there's an option for a more trimmed-down validators), but that's it. 
So it should be able to go in fine.

Joins will be redone, definitely.  They'll be put in their own module,
like Col, and a Join/SOJoin distinction will be made.  That should make
the code significantly cleaner -- not so much shorter, but it will be
clear what code gets invoked at what point of the process.  I'll
probably add a one-to-one join, and maybe a more generic join for
annotated relations (like the Worker-Customer + rate example).  Maybe
implement orderBy in the database too.  Open to consideration is join
results becomimg iterators, ala select results...

I think that's all that's been on my mind, at least short-term. 
FormEncode will start to become more involved at some point, but the
coupling will be loose -- I'm going to try to create an interface for
publishing objects (and classes) via FormEncode, and SQLObject should be
able to implement that fairly trivially (once I figure out what "that"
is).

  Ian