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