Re: [SQLObject] Temporary Objects

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

On Tue, 2003-04-29 at 04:13, Ian Bicking wrote:
> 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).

The point there is so that you can roll back an individual object rather
than the entire transaction, if desired.  Plus, you're not performing
any communication to the database, until it's completely necessary. 
Important for web services and applications, where you can send your
content so the user can see response while you do all your db writes at
the end.

> 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

The reason you would actually want to make the queries inside a
transaction for inserts and deletes is because you would want the
results to show up in subsequent selects.  On inserts, you certainly
wouldn't see new rows if they weren't sent to the db in a transactions. 
Now that I think about it, you *can* manage deletes I suppose by
checking the cache to see if the row had been deleted and then neglect
to return it in the resulting list.

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

The reason I think something like that is so important is for web based
transactions (which I assume is what started this thread).  If your
script fails for some reason, you (usually) want to roll back the entire
transaction.  Which brings me to a question... is it possible to clear
out the entire object cache so you can maintain a persistant connection
over several web requests?

Nick