[ZODB-Dev] question

[Gabriella Codes]

Thank you all for your answers. The idea of a group would do it for me, and 
would help me choose zope for the project i'm involved with.

For our needs, the group can be defined after the transaction has started, 
and  one should be able to can call commit(group) more than once, with 
different groups. Also, a new transaction should have the option of 
remembering the non-committed objects from the previous transaction.

I understand the theory of transactions, but in my realistic case (an AI 
product) we cannot conform to that theory...

Thanks again



>From: Christian Reis <kiko at async.com.br>
>To: Shane Hathaway <shane at zope.com>
>CC: Jeremy Hylton <jeremy at zope.com>, Gabriella Codes <gbcodes at hotmail.com>, 
>   zodb-dev at zope.org
>Subject: Re: [ZODB-Dev] question
>Date: Wed, 10 Sep 2003 12:29:01 -0300
>
>On Wed, Sep 10, 2003 at 11:13:06AM -0400, Shane Hathaway wrote:
> > 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.
>
>The problem that results from this is that this object may be a
>composite object, and have references to other objects that need to be
>accessible in the clone, so creating the clone itself is not trivial.
>
>Would the clone be produced using simple __dict__ introspection? Or
>something like __new__?
>
> > >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. :-)
>
>I'm not suggesting we change how the current API works -- I think it's
>wonderfully simple for the main use cases the ZODB was designed for. To
>handle "special" cases (it's pretty mainstream for us) I'm suggesting
>adding API to the transaction itself that allows it to be partially
>committed. Defining the parts that are to be committed or not could be
>done by allowing us to split the objects in the transaction into groups
>(perhaps just before the first commit() is performed).
>
>     # define a new group
>     group = transaction.create_group("Foo")
>
>     # move object from transaction to group
>     transaction.move_to_group(object, group)
>
>     # commit that object
>     transaction.commit_group(group)
>
>     time_passes()
>
>     # later, abort the rest
>     transaction.abort()
>
>Take care,
>--
>Christian Reis, Senior Engineer, Async Open Source, Brazil.
>http://async.com.br/~kiko/ | [+55 16] 261 2331 | NMFL

_________________________________________________________________
Try MSN Messenger 6.0 with integrated webcam functionality! 
http://www.msnmessenger-download.com/tracking/reach_webcam