Luciano is right, but only if you do it by hanging the counter directly off the piece of content as a property. If instead you have a persistent subobject, it simply becomes a matter of math. For instance, let's say it costs 50 bytes to store counter every time it increments. Let's then say you do 10k page views a day, which would be a site getting more than a million page views a month. You're talking about ZODB growth around 500Kb per day, or 15Mb per month. With *any* amount of packing, this shouldn't be too much of a problem. Even better are the approaches previously mentioned where counting goes in a central datastructure that queues up increments for an interval, then writes them out to some kind of storage. I don't think you _have_ to leave the ZODB to do counters. Just don't do them as a property or attribute directly attached to the thing you're counting. --Paul Luciano Ramalho wrote:
Beware of implementing counters within ZODB! Anytime you change a property of a persistent object like a Folder or DTML Document, Zope stores a new version of that object in ZODB. This leads to Data.fs severe bloat!!! Use a relational database or some other Python-only persistence mechanism to store your counter.
Best regards,
Luciano
Yann Lugrin wrote:
Hello,
I try to create a counter of which I am certain that it sends back in every Call a different result. I should so manage concurent acces on this one.
The following method is not valid I have to look for a product which could make works: ---- ID = context.nextID context.manage_changeProperties( { 'nextID' : ID+1 } ) ----
But products found (FSCounter and to threadSafeCounter) uses the File System to manage the concurrent access on the counter value.
I want to use the method described in the article " Advanced ZODB for python Programmers " ( Http://www.zope.org/Documentation/Articles/ZODB2) by creating a product based on the following code:
------------ class Counter(Persistent): self.count = 0
def hit(self): self.count = self.count + 1 return self.count
def _p_resolveConflict(self, oldState, savedState, newState): # Figure out how each state is different: savedDiff= savedState['count'] - oldState['count'] newDiff= newState['count']- oldState['count']
# Apply both sets of changes to old state: return oldState['count'] + savedDiff + newDiff ----------
Is the class "Persistent" assure the value " self.count " to be not identical in two simultaneous calls of the "hit" method (not identical return value)?
-- Yann Lugrin yann.lugrin@gmproject.net
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )