[ZODB-Dev] question

[Christian Reis]

On Wed, Sep 10, 2003 at 10:35:49AM -0400, Shane Hathaway wrote:
> Christian Reis wrote:
> >I have a reasonably simple use case that I'd like to share. I'll use as
> >an example our UI for creating a sale.
> >
> >    We have a sale dialog, in which the user is expected to enter
> >    information about a sale being processed. When I open the sale
> >    dialog I hand to it a Sale (persistent) instance, which is altered
> >    as the user manipulates the interface.
> 
> Is the Sale instance actually added to the database before handing it to 
> the dialog?  If you added it to the database only after the user has 
> clicked "Ok", you wouldn't have a transaction problem.

It's an alternative in this case, since it's a newly-created Sale.
However, say I'm editing a previously created Sale -- then it's by
definition in the database and we have the same problem.

(Or for that matter, swap Sale for Bank Account and you'll see my point)

> Alternatively, you might store the Sale instance in a temporary place 
> until the user actually confirms the sale.  You might need this if you 
> have some kind of "save for later" button on the dialog.

Where would this temporary place be, if not in the database? Otherwise
the sales that were "saved for later" will be dead when the program
restarts. 

This also doesn't work when we're altering a previously edited instance.

> In either case, you can commit or roll back transactions unrelated to 
> the sale as needed.  The general pattern is that you should avoid 
> long-lived transactions.  A dialog interaction has an unbounded length.

Well, that general pattern is a PITA! :-)

It's great to be able to use the fresh database instances in dialogs --
the code is amazingly simple, you don't need to do temporary storage
hacks -- and, most importantly of all, transactions make handling
"cancel" trivial.  That's object-oriented programming in it's full
glory!

All we need here is a way to commit a set of objects and leave the rest
(in a dirty, to-be-comitted state). Is it very hard to implement?

(One thing that might be hard is designing good API for this feature.
Maybe "object groups" in the transaction might be an idea. 

Of course, if you could invalidate parts of your current transaction,
then this would also be solved, in a different way -- the client object
could just be invalidated without ruining changes done to my sale.)

Take care,
--
Christian Reis, Senior Engineer, Async Open Source, Brazil.
http://async.com.br/~kiko/ | [+55 16] 261 2331 | NMFL