Morten's product stores the counter's value in a file on the filesystem, and so it doesn't cause the Data.fs to grow.
Hmmm, well, my counter above wouldn't cause the data.fs to grow all that much, since it subclasses Persistent and so gets its own pickle jar.
cheers,
Chris
So subclassing persistent will avoid changes to the object being stored and roll-backable in the ZODB? Nice! Now, if only we could get this sort of store-in-place functionality on a more fine-grained level (like on individual properties) - we could avoid a lot of coding to prevent ZODB bloat with simple features.. Ie, if I were to make a 'persistent porperty' on a DTML method, I could store counter information in that property without worry of ZODB bloat. Hrm... *Jon staes into the distance wondering how much will break if he tries to implement a 'persistent' flag for properties* ~Jon