[ZODB-Dev] question

[Shane Hathaway]

Christian Reis wrote:
>>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!

I'm suggesting that when you open a dialog, you make a temporary copy of 
the data.  That's not a hack--it's a standard object-oriented clone 
operation.  Implement "cancel" by discarding the copy and "ok" by 
putting the new data in the database.  It adds very little code and 
might even simplify things.

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

No, but it breaks the whole idea of transactions.  We don't want to 
think about the consequences of that decision today. :-)

Shane