Re: [SQLObject] Temporary Objects

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

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

You could keep everything in memory if you could pre-allocate IDs for
the new objects, which is kind of interesting -- if you throw the object
away, you've only lost some numbers, and numbers are cheap (103493,
10943, 23943 -- see, so cheap I can throw them away!).  Stupid MySQL
doesn't even have sequences, though, which makes this possibility
difficult.

I'm okay with deletes not being transactional (outside of using database
transactions).  I'm not sure I see as much of a use case for that.

> Obviously, this would require somewhat of a change in the DBConnector
> class (first and foremost removing conn.commit() after each query :),

Huh... I wonder why I put that commit in?

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

Certainly a database connection could be lazy and not do the update when
it was asked (but just remember to do it later).  But the idea of just
having one database connection type that did this is growing on me.

  Ian