Jeremy Hylton wrote: >>>>>>"CM" == Chris McDonough <[EMAIL PROTECTED]> 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 _______________________________________________ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )