Persistence ( was Thread Safe Counting )
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
Jon Franz wrote:
So subclassing persistent will avoid changes to the object being stored and roll-backable in the ZODB?
NO! read the posting again... Subclassing from persistent is HOW you make things live in the ZODB. However, objects that subclass Persistent get their own pickle jar, and so only make the ZODB grow by the size of themselves and their attributes each time they change. In my counter's case, that's not a lot :-)
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.
I wouldn't be surprised if something like this happens at some stage ;-) cheers, Chris
participants (2)
-
Chris Withers -
Jon Franz