[SQLObject] Re: Non-DB SQLObject instances

[Jorge G. <go...@ie...>]

Jeff Watkins <je...@me...> writes:

> Nope. This object lives across numerous pages. There may be many transactions

What's the problem with it living across pages?

> begun and committed before I decide whether to create a DB object from the
> memory version. Furthermore, given the stateless nature of the Web, I have no

So you're saying that you'd rather not have simultaneous transactions?  'Cause
I see no problem with that.

> way of knowing whether the object was abandoned --

You can put a TTL to it.  Or your database can do that for you
automatically... 

> therefore, no way to know whether to rollback the database changes.

How's that?  If you don't commit, you rollback.  Depending on your model and
database you can put a lot of things inside the same initial transaction and
later, when the user returns, you can make lots of smaller transactions to
optimize the process. 

> Support for transactions really doesn't alter the equation.

So yu had this analisys done.  :-)  I'm not familiar with the problem, but I
would think on DB persistence and cleanup routines (some kind of "dirt flag",
at least, that is cleared when the user press the button is an alternative,
modeling that with triggers and cascading deletions could clean up your
database if there's no confirmation in, lets say, 2h...).


Be seeing you,
-- 
Jorge Godoy      <go...@ie...>