- Zope-Dev - Zope lists

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

parameterised SQL methods, anyone?
by Anthony Baxter 24 Mar '99

24 Mar '99

Has anyone thought about extending the existing SQL Methods to support parameterised methods? Eg INSERT INTO foo ( cola, colb, colc ) VALUES ( :1, :2, :3 ) and providing attributes in the method to supply :1, :2, :3 &c. In databases which cache parsed SQL, this makes an enormous difference in performance... Anthony

1 0

DISCUSS: ZServer Server Manager (was RE: [Zope-dev] error when st arting with ZServer) arting with ZServer)
by Paul Everitt 24 Mar '99

24 Mar '99

[Hijacking a perfectly useful conversation...] Yesterday we got a couple of emails letting us know that some URLs weren't responding. The URLs were to ZServer-based sites and ZServer doesn't do process activation like PCGI does. Also, there was discussion here recently about a fictional mod_pcgi (or mod_zope, or whatever). One of the things brought up was that PCGI should decouple process activation from the IPC/RPC mechanism. We need to start work a "Zope Server Manager". Instead of waiting until I have everything written down, I thought I'd go ahead and start the discussion with what I have. Zope Server Manager Summary Provide a facility that registers, activates, and manages Zope processes on a system. Background Zope's current PCGI approach uses a small C executable called a "wrapper". The wrapper is run on each web request as a CGI script. Its job is to start Zope if it isn't running, package up the request, communicate with Zope, and return Zope's response to the web server. This approach has worked extremely well to date. It nicely balances adherence to a popular and simple standard (CGI) with performance/load issues. Obviously this approach has significant performance hits associated with forking and executing on each request. On Windows this can be especially painful. Digital Creations is also hard at work on ZServer, which allows an object system to publish simultaneously to PCGI, HTTP, and FTP requests. ZServer cannot have a strategy for being activated by a wrapper. It needs to have a server manager strategy. Integrating with Apache is painful, and Apache is the easiest to deal with. The frustration is usually caused by issues such as ownership of files, paths to startup scripts, vagueries with dynamically loaded modules, etc. Unfortunately, the very nature of the current PCGI approach makes it very difficult to produce meaningful error messages. Under Windows we don't have these problems. The NT Service, when combined with registry keys, allows our "wrapper" programs to find its Zope and not worry about starting or restarting it. Also, the Event Service provides a uniform way for both sides (wrapper and Zope) to report errors. Unix has facilities that mimic this. Most conspicuously, System V has a facility for init called 'inittab'. This allows sysadmins to manage a database of processes that should be started at boot time. The facility also allows you to specify that processes should be restarted if they exit. Additionally, a number of software packages have been written to act as server managers. Finally, syslog provides a uniform reporting facility. Goals o Vastly simplify integration with other web servers, thus greatly reducing the number of complaints o Speed up initial connection time o Significantly reduce the code needed for an Apache module, thus increasing reliability of something ISPs will need to load and trust o View information through the web about all ZServers running on a system, such as the information found in mod_status for Apache o Decouple the URL (web server integration) from the actual process, paving the way for features such as load balancing and failover amongst N processes o Provide a central place for Anthony to incorporate SNMP :^) Requirements *Add, edit, or disable ZServer installations*. *Manageable in user space, not by root*. --Paul

1 0

Re: [Zope-dev] error when starting with ZServer
by Service Informatique CHSR 24 Mar '99

24 Mar '99

>ZServer probably picks the cPickle file from a different installation. >Try adding the following in your start.py file in the ZServer directory. > >import sys,os >sys.path.insert(0,os.path.join('..','lib','python')) > Ok, my error was to write: import sys,os sys.path.append(os.path.join('..', 'lib', 'python')) instead of using sys.path.insert(0,xxx). Thanks to Anthony who pointed me in the right direction. But Pavlos is kind too...

1 0

RE: [Zope-dev] dev and cvs
by Ken Manheimer 23 Mar '99

23 Mar '99

> I hope this is the right place to ask this :^) The 'digicool-cvs' list would probably be better (because i follow it more carefully), but i haven't properly advertised it yet, so this one is ok. > I got and compiled cvs, it works fine. I made a quick shell script for it, > now I just type "getzope" and it goes after the latest version. No problem, > tested it Friday night. Cool! This is what i was aiming for, and i would go to some effort to rectify whatever doesn't cooperate. So far i haven't found anything... > As a newcomer to cvs I got a silly question, do I built zope in the same > directory that the cvs uses? or do I need to copy it over to a temp > directory for playing, deconstructing, etc. You shouldn't need to build elsewhere. You will notice some "?" entries cluttering up cvs updates until i set up the proper cvsignore entries, but they're harmless... Ken

1 0

Re: [Zope] one 'document' in many 'folders'
by Jim Fulton 23 Mar '99

23 Mar '99

Stefan Franke wrote: > > [Pleased of having caught Jim Fulton in verbose mode 8-] > > > You can store any complex Python data in the DB subject to: > [...] > > - Subobjects of persistent objects must be "persistent" or > > they must be immutable, or be used immutably, as in: > > So class Persistent's __setattr__ is basically also the level > that transaction and undo support work on? I'm not sure what you mean by this. Transaction boundaries are detemined by transaction calls, which are normally made by ZPublisher. Peristent's __setattr__ takes care of registering object changes. Now that you mention it, there is another restriction on persistent objects, they should not implement custom __setattr__ or __getattr__ methods. > Can I expect the undo support to work if I take care of the > persistence rules, regardless of cyclic and acyclic structures? Yes. > Propably about time to switch to Zope-dev... OK, done. :) 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.

1 0