Re: [SQLObject] Temporary Objects

[Nick <ni...@dd...>]

Hi,

I'm new to the project, but I've been working on a project that is so
similar for the past 2 years (since Python 2.2a1) that it's fairly
spooky.  I mean, the classes are even named and organized almost exactly
the same. However, my recent ex-employer owns the code, so this is the
perfect opportunity to continue working on it.

On Sat, 2003-04-26 at 11:01, Brad Bollenbach wrote:
> On 04/25/03 16:56, Luke Opperman wrote:
> > Hey all -
> > 
> > Ok, I'm going to present a possibly controversial idea. I'd like to
> > propose the concept of 'temporary' objects, for use in cases where
> > you want to save values (say from a series of web forms) in
> > SQLObject-constrained containers (columns, relationships), but don't
> > want to persist to the database until the user finishes the process.
>
> Your motives are well-founded, but I don't entirely agree with your
> choice of metaphor.
> 
> What you're really looking for is transactions.

Right on, that's what I did with my code.  What I did was never run any
queries and keep a pool of "dirty" object to commit when a commit() call
was made, and rollback() would reset to original values.  new()s and
delete(s) obviously can't be done this way or it will screw up
subsequent queries, so the DBIs transaction model was used in addition
to the pool.  It worked really well.

Obviously, this would require somewhat of a change in the DBConnector
class (first and foremost removing conn.commit() after each query :),
but since there's a fairly complete caching mechanism it's only a matter
of marking objects as dirty when modifications are made and then
checking the cache and running an update() on every dirty object.

Nick