[ZODB-Dev] question

[Christian Reis]

On Wed, Sep 10, 2003 at 10:01:11AM -0400, Jeremy Hylton wrote:
> > 2) How can i have fine grained control over what objects are
> > persisted? I saw that one can specify the beginning and end of a
> > transaction, and commit, but what if one does not want to save ALL
> > the objects that have been modified, only select ones?
> 
> ZODB does not provide programmer control over what objects are saved. 
> The transaction API is the only intended way to propagate changes to
> other clients and to make them persistent.  The goal is to free
> programmers from details like what and when to save, because those
> details are hard to get right.
> 
> Do you have a specific concern?  If you explain what your goal is, we
> might be able to offer some design hints on how to achieve it in a
> transactional framework.

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.

    On the dialog, there's an autocomplete widget which allows the user
    to select a customer to sell to, and a button which allows the user
    to update the customer's data as part of the sale process.

    When the user clicks on the edit button, a dialog allowing him to
    alter the customer data is opened. The user may change the customer
    data and dismiss the dialog by clicking "OK" or "Cancel".

    When the user clicks "OK" on the customer data dialog, we are
    presented with a dilemma: 
    
        - On one hand, if I call commit(), I will commit changes to the
          Sale instance which is in the process of being edited. But we
          can't be sure we *should* commit those changes, because the
          user can dismiss *the sale dialog*, in which case the sale we
          committed will have to be undone. 
          
          So, conceptually, commit() of the Sale should only happen when
          the *sale dialog* is confirmed, not any subdialog. However, I
          can't tell the transaction to only commit the Customer and not
          the Sale.

        - However, if I *don't* call commit() when closing the customer
          dialog, and the user dismisses the sale dialog, no commit() is
          ever performed, and the customer's updated information
          (address, etc) is lost. This is bad usability, and an annoying
          problem occasionally.

    Using a separate connection for the customer dialog and commit()ing
    *that* connection when confirming that dialog is a problem, because
    the connection the *sale* is in can't "see" the changes done to the
    customer until a transaction boundary is crossed -- and I can't call
    sync(), or my object's data is lost.

What would a reasonable way to implement this be, or is this a good
example of why we need finer-grained control over transactions? :-)

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