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

[Steve Alexander]

Jeremy Hylton wrote:
>>>>>>"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.

This might be possible without incremental packing, if the object will 
be of a fixed size.

I'm thinking of a simple counter here, something like:

class Counter(object):

   __slots__ = ['__count']

   def __init__(self):
     self.__count = 0

   def increment(self):
     self.__count += 1

   def getValue(self):
     return self.__count

Now, imagine that Counter was somehow Persistent too. (There would need 
to be a few more _p_... declarations in __slots__, and possibly some 
changes in the persistence machinery to allow for slots based instances 
as well as __dict__ based ones.)

I would naively expect a pickle of Counter instance to always remain the 
same size. Therefore, it could be updated in-place.

Of course, this would break various other nice behaviours of FileStorage.


Another variation on the same theme: have a fixed-size "external 
reference" instead of the object's pickle. The fixed-size reference 
points to a separate some_object.pickle file which contains the pickle 
for that one object. The some_object.pickle file gets overwritten on 
each update.

--
Steve Alexander