[Zope-dev] RE: [Zope] Counters

[Shaw, Howard]

I take it that you mean I ought to construct a persistent Product, which
stored the values internally? I am afraid I know nothing about
persistence, in particular, what determines whether and when a
persistent Product's instance is written or rewritten to the database? 

Howard C. Shaw III
Programmer/SysAdmin
St. Thomas High School


> ----------
> From: 	Paul Everitt[SMTP:Paul@digicool.com]
> Sent: 	Wednesday, March 24, 1999 1:53 PM
> To: 	'Shaw, Howard'; 'Zope@zope.org'
> Subject: 	RE: [Zope] Counters
> 
> 
> Howard wrote:
> > I remember noticing various comments on the list bemoaning the lack
> of
> > some sort of counter. I also remember noticing the objections 
> > which were
> > raised, and why counters weren't feasible. I don't remember reading
> > these objections, which may be why when I found a need for a 
> > counter, I
> > sat down and wrote one. I now have a working Counter product which
> > provides a <!--#counter--><!--#/counter--> tag .
> 
> I'll indicate my appreciation of your contribution by, well, asking
> for
> more! :^)
> 
> One of the big objections of the counter kind of object is that the
> object database gets bigger on every request.  A good workaround for
> this would be to cache writes to the database.
> 
> Thus, imagine a counter that:
> 
> 1) Only wrote to the database after a threshold had passed.  For
> instance, only every tenth state change or not until ten minutes had
> elapsed since the last write.
> 
> 2) If the process was nicely shut down, the object would save itself.
> 
> 3) Had knobs in the management screen that allowed adjusting the
> "buffered write" policy.
> 
> The benefits:
> 
> 1) The database wouldn't keep versioning into oblivion.
> 
> 2) The application wouldn't be slowed by writes on every request.
> 
> The drawbacks:
> 
> 1) If the process exited not nicely, some state changes would be lost.
> 
> --Paul
>