Re: [SQLObject] Temporary Objects

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

On 04/29/03 04:13, Ian Bicking wrote:
> On Sat, 2003-04-26 at 12:48, Nick wrote:
> > 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. 
> 
> It's because I'm inside your head!
> 
> > 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.
> 
> That seems confusing to me.  If you're going to use database
> transactions, why not just use them entirely?  You only seem to really
> gain something if you can avoid them entirely (and thus make it possible
> to add transactions to lesser databases).

To be useable with database backends that don't support transactions
natively, and to provide a consistent interface for using them either
way.

-- 
Brad Bollenbach
BBnet.ca