On Jun 1, 2007, at 6:07 AM, Kai Diefenbach wrote:

Stefan H. Holek <[EMAIL PROTECTED]> wrote:

Counting in the ZODB is more or less a no-go. You will get write
conflicts, and your ZODB will grow (too) quickly.

I kind of doubt that updating a little counter will make the database grow "too" quickly, but that might depend on how often the counter was updated and how you defined "too". :)

An issue with current ZODB storage implementations is that they require explicit packing to remove old revisions and, in the case of the file storage implementation, packing is rather expensive. (I think the FileStorage pack implementation could be improved quite a bit in this regard.) If you have a very busy counter, you might have to pack more often then you otherwise would.

But what's an alternative?

That depends on the underlying use case. If you want to track traffic, there's always log analysis. :)

In general I don't like the thought to use a RDBMS in parallel to Zope's
ZODB approach. And more than ever for a counter.

If the counter if updated a lot, then transactional databases, including most RDBMSs and ZODB are likely to be too slow, again, for some definition of "too".


Jim Fulton                      mailto:[EMAIL PROTECTED]                Python 
CTO                             (540) 361-1714                  
Zope Corporation        http://www.zope.com             http://www.zope.org

For more information about ZODB, see the ZODB Wiki:

ZODB-Dev mailing list  -  ZODB-Dev@zope.org

Reply via email to