March 1999 - Zope-Dev

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

Re: [Zope-dev] Product access to IP
by Philip Aylesworth 24 Mar '99

24 Mar '99

>Is there a function or request variable which would tell me from within >a product what IP address had requested the page? I am writing a counter >product, which is working, thanks to Jim Fulton, but I would like to >keep a log of recently registered IPs and not up the counter when they >connect, to prevent 'running up' of the counter. To do this, I need to >access the IP address of the machine requesting the web page.  will do it. Phil A ------------------------------------------ Philip Aylesworth zopelist(a)regalint.com Regal International

1 0

Product access to IP
by Shaw, Howard 24 Mar '99

24 Mar '99

Is there a function or request variable which would tell me from within a product what IP address had requested the page? I am writing a counter product, which is working, thanks to Jim Fulton, but I would like to keep a log of recently registered IPs and not up the counter when they connect, to prevent 'running up' of the counter. To do this, I need to access the IP address of the machine requesting the web page. Thanks all. Thanks especially to Jim Fulton for solving my earlier problem. Howard C. Shaw III Programmer/SysAdmin St. Thomas High School

1 0

RE: [Zope-dev] RE: [Zope] ZOracleDA and long numbers
by TFE MMS JARVIS JOHN 24 Mar '99

24 Mar '99

doh! It's already in there... Thank you! > -----Original Message----- > From: Jim Fulton [SMTP:jim@digicool.com] > Sent: Wednesday, March 24, 1999 10:49 PM > To: TFE MMS JARVIS JOHN > Cc: zope-dev(a)zope.org > Subject: Re: [Zope-dev] RE: [Zope] ZOracleDA and long numbers > > > > TFE MMS JARVIS JOHN wrote: > > > > (moving this to zope-dev where it probably belongs...) > > > > It looks like floats are the best way to work around this after all. > Using > > longs makes it neccessary to not only put fmt's on in my document tags > > but in all my sql methods as well. Oracle doesn't want to believe that > 98L > > is a number ;) > > > > Is this something that should be reported to the bug collector as a > > feature request for large number support perhaps? > > Sure. Not sure if it has already been entered. > > Jim > > -- > Jim Fulton mailto:jim@digicool.com Python Powered! > Technical Director (888) 344-4332 http://www.python.org > Digital Creations http://www.digicool.com http://www.zope.org > > Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email > address may not be added to any commercial mail list with out my > permission. Violation of my privacy with advertising or SPAM will > result in a suit for a MINIMUM of $500 damages/incident, $1500 for > repeats. > > _______________________________________________ > 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

Product tag accessing containing namespace?
by Shaw, Howard 24 Mar '99

24 Mar '99

How can a product such as the contributed Calendar product, which adds a new tag, within the code which renders said tag, access the namespace of the containing document? Howard C. Shaw III Programmer/SysAdmin St. Thomas High School

2 1

RE: [Zope] ZOracleDA and long numbers
by TFE MMS JARVIS JOHN 24 Mar '99

24 Mar '99

(moving this to zope-dev where it probably belongs...) It looks like floats are the best way to work around this after all. Using longs makes it neccessary to not only put fmt's on in my document tags but in all my sql methods as well. Oracle doesn't want to believe that 98L is a number ;) Is this something that should be reported to the bug collector as a feature request for large number support perhaps? > -----Original Message----- > From: TFE MMS JARVIS JOHN > Sent: Wednesday, March 24, 1999 7:29 PM > To: 'Jim Fulton' > Cc: zope(a)zope.org > Subject: RE: [Zope] ZOracleDA and long numbers > > > Thanks for the pointer! > > I have to retract what I said in a previous post about not having a > problem with the ZODBCDA--it has the same problem. I had made a small > hack of a product for my own study that connected through ODBC and > that didn't have the problem because I used Python longs. I somehow > got the two confused... > > This works, but everything gets converted to floats like you said. In > my case, this is not so much a problem because I use a lot of large > numbers but doesn't seem practical for general use. > I found that if, in Buffer.c, I change lines 143 and 144 to > > case 'd': > return PyLong_FromDouble(self->val.d[ii]); > > I can get the same results as my product--everything is a > long. Unfortunately, this causes everything to be printed with > Python's 'L' appended instead of '.0'. Either can be fixed by > using fmt="%.f" to all of my number fields, but that seems like a > lot of extra work (maybe a quick hack to the Z Search Interface > would do the trick?) > > Plus, what if I really have floats somewhere? Would something like: > > elif dbtype==2: # Number > if scale: > buf=Buffer(arraysize,'f') > dbtype=4 > dbsize=8 > else: > buf=Buffer(arraysize,'d') > dbtype=4 > dbsize=8 > > in ociCurs.py (lines 123-131) handle this? I haven't tested it yet on > float fields. It might be better to just leave everything as floats. > > John Jarvis > Tokyo Electron FE, Ltd. > > > -----Original Message----- > From: Jim Fulton [SMTP:jim@digicool.com] > Sent: Wednesday, March 24, 1999 12:00 AM > To: TFE MMS JARVIS JOHN > Cc: zope(a)zope.org > Subject: Re: [Zope] ZOracleDA and long numbers > > > > TFE MMS JARVIS JOHN wrote: > > > > Hi all! > > > > I'm having a problem with running queries containing long numbers. > > I found in db.py that the data type NUMBER is converted to an > > integer which overflows in my case. > > > > The errors: > > > > Error, oci.error: (1455, 'ORA-01455: converting column overflows > integer > > datatype\012') > > > > Traceback (innermost last): > > File /usr/lib/python1.5/ZPublisher/Publish.py, line 877, in > publish_module > > File /usr/lib/python1.5/ZPublisher/Publish.py, line 590, in > publish > > (Info: /queries/wisdom/customer-Line/manage_test) > > File /usr/lib/python1.5/Shared/DC/ZRDB/DA.py, line 305, in > manage_test > > (Object: CopySource) > > File /usr/lib/python1.5/Shared/DC/ZRDB/DA.py, line 286, in > manage_test > > (Object: CopySource) > > File /usr/lib/python1.5/Shared/DC/ZRDB/DA.py, line 390, in > __call__ > > (Object: CopySource) > > File db.py, line 198, in query > > File /usr/lib/python1.5/Products/ZOracleDA/DCOracle/ociCurs.py, > line 317, > > in fetchmany > > File /usr/lib/python1.5/Products/ZOracleDA/DCOracle/ociCurs.py, > line 279, > > in fetchone > > File /usr/lib/python1.5/Products/ZOracleDA/DCOracle/ociCurs.py, > line 75, > > in _error > > oci.error: (see above) > > > > I tried changing line 219 in query() in db.py: > > from > > if scale==0: type='i' > > to > > if scale==0: type='f' > > > > in order to force a float type, but this has no effect, it seems. > > This typr only affects meta-data seen by some Zope tools. > > > I'm sure that I'm misunderstanding something here. > > Nope, you aren't. > > > Any pointers to where I can look to fix this would be greatly > > appreciated. > > There is a similar change that needs to be made to *work around* > this problem. In DCOracle/ociCurs.py, change: > > elif dbtype==2: # Number > if scale: > buf=Buffer(arraysize,'d') > dbtype=4 > dbsize=8 > else: > buf=Buffer(arraysize,'i') > dbtype=3 > dbsize=4 > f=None > > to: > > elif dbtype==2: # Number > if scale or 1: > buf=Buffer(arraysize,'d') > dbtype=4 > dbsize=8 > else: > buf=Buffer(arraysize,'i') > dbtype=3 > dbsize=4 > f=None > > This has the undesirable effect of causing all > numbers to be treated as ints. (This is what oracledb > does) :( Unfortunately, you can't tell from Oracle column > meta data whether values in a column will fit into Python ints. > > The right way to fix this is to implement Oracle's > NUMBER or VARNUM C data types and convert to Python > ints or longs on a case by case basis. > > Jim > > -- > Jim Fulton mailto:jim@digicool.com Python Powered! > > Technical Director (888) 344-4332 http://www.python.org > > Digital Creations http://www.digicool.com http://www.zope.org > > > Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This > email > address may not be added to any commercial mail list with out my > permission. Violation of my privacy with advertising or SPAM will > result in a suit for a MINIMUM of $500 damages/incident, $1500 for > repeats.

2 1