[Zope-dev] how bad are per-request-write-transactions

[Jeremy Hylton]

>>>>> "CM" == Chris McDonough <chrism@zope.com> writes:

  >> Completely agreed.  My disagreement is portraying the counter
  >> problem as impossible with the zodb.  I think some people, as
  >> evidenced by some of the responses, are willing to live with the
  >> tradeoffs.  Other people will find managing a log file on disk to
  >> be a more manageable solution.

  CM> It would be best to make make a dual-mode undoing and nonundoing
  CM> storage on a per-object basis.

I'd really like to do this for ZODB4, but it seems hard to get it into
FileStorage, without adding automatic incremental packing to
FileStorage.

Example: Object A is marked as save enough revisions to do a single
undo.  When a transaction updates A and makes older revisions
unnecessary, there's no obvious way to remove them without doing a
pack.  We could write a garbage collector that removed unneeded things
(as opposed to packing everything to a particular date), but it
doesn't seem very useful if it needs to be run manually.

Also, how would you specifiy the object's packing policy?  I'm
thinking an _p_revision_control attribute or something like that.  If
the attribute exists on an object, it sets a particular policy for
that object.  

Do individual transactions need to play in this game, too?  I'm
imagining a use case where an object is marked as "no revisions" but
you want to be able to undo a particular transaction.  I'm not sure if
that means :

    - you can undo the transaction, but the "no revisions" object
      keeps its current state.

    - you can undo the transaction, and because the transaction is
      specially marked as undoable, there actually is a revision

    - you can't undo the transaction

The first choice seems appropriate for a counter (I think), but I'm
not sure if it makes sense for all possible revision-less objects.

Jeremy