- Zope-Dev - Zope lists

RE: [Zope-dev] New Counter Product
by Michel Pelletier 25 Mar '99

25 Mar '99

> -----Original Message----- > From: Shaw, Howard [mailto:ShawH@STHS.org] > Sent: Wednesday, March 24, 1999 7:11 PM > To: 'Zope-Dev(a)zope.org' > Subject: [Zope-dev] New Counter Product > > > Well, it is basically finished and working, combining a > visible Product > interface and a counter tag... But, overriding __setstate__, removing > the temporary entry from the state, and called > Persistent.__setstate__, > while generating no errors, fails to prevent the temporary entry from > being written into the database. Please help, I need two answers! > > 1. How can I create a variable within a Product that will not be > persistent (i.e. will not be written to disk)? > Prefix your variable name with _v_. If you don't want the attribute foo to be persistent, call it _v_foo. > 2. What function is called at normal shutdown? I need to call > a function > at shutdown to move the current value from temp to real. > Uhm.. there isn't a shutdown hook for Products. Is this what your looking for? > Note: The counter is usable as is, so if the list members think that > Paul's now repudiated fear of constant disk growth is a non-issue, I > could drop the temporary variable, and just keep the advantages of the > interface, and the potential for an SQL based backend whilst > keeping the > same front-end. > > Thanks again. > > Howard C. Shaw III > Programmer/SysAdmin > St. Thomas High School > -Michel > > _______________________________________________ > Zope-Dev maillist - Zope-Dev(a)zope.org > http://www.zope.org/mailman/listinfo/zope-dev > > (For non-developer, user-level issues, use the companion list, > zope(a)zope.org, http://www.zope.org/mailman/listinfo/zope ) >

1 0

RE: [Zope-dev] New Counter Product
by Shaw, Howard 24 Mar '99

24 Mar '99

Well, except for the debugging and the interconnection of the class that provides the tag with the class providing persistence its almost done, assuming the Persistent.__setstate__(self,state) call works. BTW, is it a bad thing for me to modify state, or should I modify a copy of state, and pass that instead? What does the list think? Should I just run with Counter as written, or write the update? The advantages of the update should be... * Compresses updates by a specified amount. I.e. doesn't write to db until X hits go by * Has visible management interface * Doesn't clutter up folder properties * Has security (You can prevent X from using counters, while allowing Y to) * Separates rendering from recording so rendering can occur in disparate locations from same counter * Should be easier to generate separate product with matching interface that uses SQL DB to store info and/or product that stores more info than just the IP, but use the same rendering tag... (I think...) The disadvantages would be... * More complicated source code * Requires adding a Counter object AND a tag, rather than just a tag Howard C. Shaw III Programmer/SysAdmin St. Thomas High School > ---------- > From: Paul Everitt[SMTP:Paul@digicool.com] > Sent: Wednesday, March 24, 1999 4:33 PM > To: 'Shaw, Howard' > Subject: RE: [Zope-dev] New Counter Product > > > Howard wrote: > > addition to > > the database of 4K. I am not sure that this is a significant > > amount, but > > I retract my statement. You're right -- it doesn't warrant the extra > complexity, so consider your hit counter contributed! > > --Paul >

1 0

func called when Zope closes?
by Shaw, Howard 24 Mar '99

24 Mar '99

What function of the Product does Zope attempt to call during a normal shutdown to inform it that the system is going down? Howard C. Shaw III Programmer/SysAdmin St. Thomas High School

1 0

RE: [Zope-dev] New Counter Product
by Shaw, Howard 24 Mar '99

24 Mar '99

Read Paul's message in the Zope list. He pointed out that because the ZODB uses a logfile structure (i.e. an append based mechanism where changes are appended rather than overwritten) something such as a counter which changes with each access will write to the database (appending, not overwriting) with every access. On a site with enough traffic to really warrant a counter, this could cause the database to grow significantly in a short amount of time. Can you imagine the amount of writing if the server got Slashdotted? Since my code uses Longs, which are (I assume) stored as strings (since no binary format exists to handle arbitrary lengths) wherefore a base count of 4000 hit by a Slashdot effect resulting in a 1000 hits results in a minium addition to the database of 4K. I am not sure that this is a significant amount, but Paul seems to think it would be better if the hits were accumulated before being written. This requires some place to temporarily store data... persistently as far as memory is concerned, but not persistent with regard to disk storage. The only way I can think to do this at the moment is to create a persistent Product, and force some of its attributes to fail to be seen by the persistence mechanism. At this point, my primary question is how do I, within my own __setstate__, call the original __setstate__? My guess is Persistent.__setstate__ and pass self in manually, but I would welcome advice. Thanks again. Howard C. Shaw III Programmer/SysAdmin St. Thomas High School > ---------- > From: Mike Pelletier[SMTP:mike@compar.com] > Sent: Wednesday, March 24, 1999 3:48 PM > To: Shaw, Howard > Subject: Re: [Zope-dev] New Counter Product > > > I don't understand... Why does the underlying persitance > mechanism matter > at all? And why do you want to not pickle certain instance > attributes? If I > knew that, it would be much clearer to me. > > Mike. > > > -- > --- | Mike Pelletier Work: > 519-746-1607 > /opeware! | Software Developer Home: > 519-725-7710 > --- | mike(a)zopeware.com Fax: > 519-746-7566 > http://www.zopeware.com | Zopeware is not endorsed by Digital > Creations >

1 0

ZopeHTTPServer patch for userid
by Christopher Petrilli 24 Mar '99

24 Mar '99

Gang, I was bored, annoyed with this silly being forced to run something as nobody (since I'm using ZopeHTTPServer), and since it's a trivial fix, attached is a patch that behaves the same by default, but adds a command line option to ZopeHTTPServer which lets you specify the userid tor un as (obviously you must be able to change your userid)... it's still defaults to nobody. The option is.... </drumroll> -u ;-) You can also find the patch verbatim on the web: http://www.amber.org/petrilli/Technical/Python/Zope/ZopeHTTPServer.py.patch Have fun... bitch at me ;-) CHris -- | Christopher Petrilli ``Television is bubble-gum for | petrilli(a)amber.org the mind.''-Frank Lloyd Wright

1 0

New Counter Product
by Shaw, Howard 24 Mar '99

24 Mar '99

Alright, pursuant to Paul's request, I am working on a persistent Counter which will store the counter value internally, rather than in folder properties. It should allow access, assuming I can get this figured out, through the same style tags, but these would specify an id which would map to the Counter object to access, whether for display, increment, or both. But now, I need to know, having 'mixed-in' the Persistence class, when do my attribute assignments write to the DB, and when don't they, and how can I get an internal variable in the persistant class instance that does not get written to the DB? C'mon Paul, if you want this, I have to know! I can't do it any other way, except by making the Counter product inherently dependent on a relational database, and that promises all sorts of ugliness. Somebody please help! Howard C. Shaw III Programmer/SysAdmin St. Thomas High School

1 0

FYI: Slightly updated version of the Z ODB tech docs
by Paul Everitt 24 Mar '99

24 Mar '99

I've gotten a lot of reports about a broken link to the ephemeral, much-referenced "BoboPOS3a1" technical docs. I promised myself I wouldn't update the link unless I updated Jim's doc to Zope-ify it. Thus: 1) The official name of the database is "ZODB", the Z Object Database. 2) The News on the site has a link to the ZODB3 Technical Documentation. This is a very well written, circa October document from Jim Fulton that describes the architecture of the next version of the database (i.e. Zope2). It's quite nice -- contains UML diagrams, API discussions, etc. 3) The broken links have been updated. --Paul Paul Everitt Digital Creations paul(a)digicool.com 540.371.6909

1 0

RE: [Zope] Counters
by Shaw, Howard 24 Mar '99

24 Mar '99

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(a)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  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 >

1 0

RE: [Zope-dev] Who wrote the Calendar tag?
by Shaw, Howard 24 Mar '99

24 Mar '99

I believe the original contribute was tsarna(a)endicor.com Howard C. Shaw III Programmer/SysAdmin St. Thomas High School > ---------- > From: David Brown[SMTP:davidbro@home.com] > Sent: Wednesday, March 24, 1999 1:22 PM > To: zope-dev(a)zope.org > Subject: [Zope-dev] Who wrote the Calendar tag? > > I'm curious because after playing with it, I modified it a little > (and fixed a bug), and I want to give my changes back. > > To summarize my changes: > > I added 3 properties - > > bordercolor: controls the color of the border the calendar > draws around the elements (default '000000') > > spacing: the spacing between calendar elements (also the > width of the border drawn in 'bordercolor') (default 2) > > padding: the padding within each calendar element's cell > (default 4) > > They are coded so that if you don't specify them, the calendar > draws as it always has. > > The bug that I fixed concerned the setting of the 'right' property, it > seems that the code would ignore any settings you provided and used > the default value. I changed it so that it only uses the default if > it was not previously set. > > If people want me to, I can just post it to the list, but I'd > rather send it to the original author, and let them upload it > to the contribution area on zope.org. > > dave > > _______________________________________________ > Zope-Dev maillist - Zope-Dev(a)zope.org > http://www.zope.org/mailman/listinfo/zope-dev > > (For non-developer, user-level issues, use the companion list, > zope(a)zope.org, http://www.zope.org/mailman/listinfo/zope ) >

1 0

Who wrote the Calendar tag?
by David Brown 24 Mar '99

24 Mar '99

I'm curious because after playing with it, I modified it a little (and fixed a bug), and I want to give my changes back. To summarize my changes: I added 3 properties - bordercolor: controls the color of the border the calendar draws around the elements (default '000000') spacing: the spacing between calendar elements (also the width of the border drawn in 'bordercolor') (default 2) padding: the padding within each calendar element's cell (default 4) They are coded so that if you don't specify them, the calendar draws as it always has. The bug that I fixed concerned the setting of the 'right' property, it seems that the code would ignore any settings you provided and used the default value. I changed it so that it only uses the default if it was not previously set. If people want me to, I can just post it to the list, but I'd rather send it to the original author, and let them upload it to the contribution area on zope.org. dave

1 0