[ZODB-Dev] Fixing POSKeyErrors :-)

Jim Fulton jim at zope.com
Thu Feb 14 09:34:29 EST 2008


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




More information about the ZODB-Dev mailing list