[ZODB-Dev] question

Christian Reis kiko at async.com.br
Wed Sep 10 13:29:01 EDT 2003


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



More information about the ZODB-Dev mailing list