[Zope-dev] Proposed solution for ZODB woes

[Kevin Dangoor]

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.