Though I admit that I'm not familiar with the inner workings of this part of Zope, I have a feeling that what you're suggesting is a lot of work. There is an existing alternative right now in the form of SQL databases. Just store any of your frequently changing things (hit counters and the like) in there. Yes, I know that's not very Zopish though. Two more possibilities: 1) Longer term, Jim has talked about being able to use multiple storages simultaneously. This would allow you to set up one storage for your frequently changing stuff and one for your less frequently changing things. 2) Or, implement a new storage (maybe an SQL storage). There's already Berkeley Storage, which doesn't have the growth issue of FileSystem, but also doesn't support versions and undo. If you make a storage that attaches to Postgres, you can probably get everything. Gotta love a system as extensible as Zope :) Kevin ----- Original Message ----- From: "Lalo Martins" <lalo@hackandroll.org> To: "Zope-Dev" <zope-dev@zope.org> Sent: Friday, February 18, 2000 8:21 PM Subject: [Zope-dev] Proposed solution for ZODB woes
Right now we have a provision for non-persistent variables (with _v_, which I assume is for ``volatile''). The obvious way to fix the incontrolable growth of ZODBs is creating a new prefix for ``non-undoable'' variables, perhaps _t_.
Implementation-wise, these variables would be stored in a different area. For filesystem storage, the best implementation is probably using a second file for all _t_ stuff. (Actually, they can be kept in RAM and only synced to this file periodically).
The other part is giving Zope objects a way to have _t_ and perhaps even _v_ properties.