[Zope-dev] Non Bloating Page Counter

[kapil thangavelu]

On Friday 08 November 2002 01:55 pm, Dieter Maurer wrote:
> Brian R Brinegar writes:
>  > We've had requests from several of our users for the ability to have a
>  > drop in page counter within zope. However creating a page counter python
>  > script which increments some value in zope will bloat the ZODB.
>  >
>  > Solutions exist where values are stored on the file system or in a
>  > database. Unfortunately our users don't have file system access and it
>  > is unacceptable to expect them to request a database account and setup
>  > database connections and methods just to create a page counter.
>  >
>  > I would like to create a Page Counter product that doesn't bloat. If a
>  > product is created that doesn't subclass History or UndoSupport does it
>  > still bloat?
>
> It does.
>
> The bloat is a consequence of how "FileStorage" works (I appends
> changes at the end of the file and does never override something).
>
> You need a different storage (a non-undoable one) to prevent
> this behaviour, e.g. BerkeleyStorage or OracleStorage.

is there a useable undoable storage?

> When your load is light and your counter consists justs of
> an integer, then your bloat is only several dozens of byte
> and you may be able to live with it....


if you can live with that, then you should try to use a subclass of 
lib/python/BTrees/Length.py

more efficient pickling state and app conflict resolution.

stepping up beyond that while remaining in the zodb means using something like 
the strategy casey suggested of updating in memory variables and committing 
them periodically (and you definitely want conflict resolution for something 
like that on your persistent ob).

-k