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