"Andy McKay" <andym@ActiveState.com> wrote:
| The ideal solution would be to use an object that lives in the ZODB, | I wonder if there is a way to keep the 'object history' empty? That | is, keeping the counter 'packed' while retaining 'object history' | information on all other objects.
That would work, however I just dont think that fits neatly into the ZODB in any way since all objects are appended.
Small confusion here: "ZODB" is a higher-level abstraction than "FileStorage"; it is quite feasible to have one or more storages inside your Zope which are "packless" / "undo-less", and which then have the space efficiencies you are looking for (often at a non-trivial time cost). Tres. -- =============================================================== Tres Seaver tseaver@digicool.com Digital Creations "Zope Dealers" http://www.zope.org
Tres Seaver wrote:
...it is quite feasible to have one or more storages inside your Zope ... often at a non-trivial time cost.
Where does the time cost come in? I've noticed a delay on first mounting another storage, but I haven't looked for a delay on accessing objects in the storage. -- Steve Alexander Software Engineer Cat-Box limited http://www.cat-box.net
On Wed, 14 Feb 2001, Steve Alexander wrote:
Tres Seaver wrote:
...it is quite feasible to have one or more storages inside your Zope ... often at a non-trivial time cost.
Where does the time cost come in? I've noticed a delay on first mounting another storage, but I haven't looked for a delay on accessing objects in the storage.
I was talking about a time cost for "packless" storage; updates are typically harder to do, especially in a transactional way, than appends. I don't have any sense that mounted storages induce significant performance penalties. Tres. -- =============================================================== Tres Seaver tseaver@digicool.com Digital Creations "Zope Dealers" http://www.zope.org
That would work, however I just dont think that fits neatly into the ZODB in any way since all objects are appended.
Small confusion here: "ZODB" is a higher-level abstraction than "FileStorage"; it is quite feasible to have one or more storages inside your Zope which are "packless" / "undo-less", and which then have the space efficiencies you are looking for (often at a non-trivial time cost).
Is where anyway to pack an ExternalMount without having to unmount it first? Could it be setup to do inside Zope? How does DC handle this on zope.org (I believe the wikis are on a ExternalMount, if I'm not mistaken) Johan
On Wed, 14 Feb 2001, Johan Carlsson wrote:
Small confusion here: "ZODB" is a higher-level abstraction than "FileStorage"; it is quite feasible to have one or more storages inside your Zope which are "packless" / "undo-less", and which then have the space efficiencies you are looking for (often at a non-trivial time cost).
Is where anyway to pack an ExternalMount without having to unmount it first? Could it be setup to do inside Zope?
I'm unsure about this.
How does DC handle this on zope.org (I believe the wikis are on a ExternalMount, if I'm not mistaken)
We never pack the wikis storage: that difference in policy is actually the reason we moved wikis to a separate storage in the first place. The other thing about the zope.org storages is that they are all served by a ZEO storage server; hence, I think it would be feasible to create an additional ZEO client, which used the main site's "sub-storage" as its own main storage; one would then be able to pack it (I think), while leaving the main site running (but more slowly during the pack). Tres. -- =============================================================== Tres Seaver tseaver@digicool.com Digital Creations "Zope Dealers" http://www.zope.org
participants (3)
-
Johan Carlsson -
Steve Alexander -
Tres Seaver