On Feb 13, 2008, at 11:28 PM, Paul Winkler wrote:
On Wed, Feb 13, 2008 at 07:34:20PM -0500, Jim Fulton wrote:
On Feb 13, 2008, at 6:14 PM, Binger David wrote:
On Feb 13, 2008, at 3:58 PM, Jim Fulton wrote:
Note that, IMO, some of the best use cases for multi databases are
separating catalog and session data from regular content.
Could you say more about what the benefit of this separation is,
Catalogs and session data change much faster than content. It
makes sense
to pack these more frequently. On large system, it provides the
ability to
spread load over multiple servers, if necessary.
Also, as I understand it, you can get more benefits from the "regular
content" ZODB cache if you're not constantly moving tons of catalog
data through it, so there's a performance win.
Yup.
We've been discussing doing this for openplans.org... one question
that came up that none of us knew the answer to: If I undo some
changes to content, what happens to the index values for that content?
Does undo fire an ObjectModifiedEvent? If not I'd guess that the
catalog will still contain pre-undo data.
That is another weakness in the multi-database approach -- undo isn't
aware of multiple databases. Since undo isn't widely used for various
reasons, this isn't a big deal, still, it would be nice if it worked.
If you're using catalogs, then undo generally doesn't work anyway,
because changes to the catalogs by subsequent transactions make undo
impossible. A queued catalog, in addition it improving performance,
should make undo work, even when catalogs are in a separate database.
This is because the queue supports conflict resolution in a way that
should allow undo and, as you suggested above, undoing a queued-
catalog event has the effect of generating a new catalog event.
Jim
--
Jim Fulton
Zope Corporation
_______________________________________________
For more information about ZODB, see the ZODB Wiki:
http://www.zope.org/Wikis/ZODB/
ZODB-Dev mailing list - ZODB-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zodb-dev
