On Wednesday 06 November 2002 8:33 am, Janko Hauser wrote:
Just an idea from the 'could-be-done-if-needed-department'. Generally
there is quite often the need to have non-undoable properties in
different objects of a site. There is one way to store it in the
temporary storage, which is ram
kt == kapil thangavelu [EMAIL PROTECTED] writes:
e.g. BerkeleyStorage or OracleStorage.
kt is there a useable undoable storage?
I think you meant useable non-undoable storage, right?
If so, then I believe that ZODB 3.2 will have a such a useable
storage. We've had some recent
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
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
Hello,
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.
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?
those have nothing to do with the fact that every time that hit counter
fires some object will get updated and thus saved again.
Zope is
