Zope-Dev August 1999

zope-dev@zope.dev

85 participants
206 discussions

Re: [Zope-dev] Another zope suggestion
by Christopher Petrilli 13 Oct '99

13 Oct '99

> Would it be possible to have a Zope feature to change the Python path > from Zope? Could you elaborate on what problem you are trying to solve? THis sounds awfully scary and frightening to me :-) Chirs -- Chris Petrilli

2 1

thread safety in external methods
by Robin Becker 03 Sep '99

03 Sep '99

How do I do thread safety inside an External method. I want to access a global singleton as def __ZGA(): if not hasattr(sys.modules['__main__'],'__ZGA'): #unsafe here... Z=ZGA_calculator() # initialise things to do with Z sys.modules['__main__'].__dict__['__ZGA']=Z return sys.modules['__main__'].__dict__['__ZGA'] the problem is controlling access to sys.modules['__main__'].__dict__['__ZGA']. I can't have a global lock inside my external method as I get a different environment with each call (which is why I need the singleton in the first place). It would be sufficient for my purposes if I could guarantee to get certain code run just once at startup time. Do I have to make a product or is there some easier way to do this. -- Robin Becker

3 7

I won't be using ZDaemons heartbeat for ZScheduler
by Martijn Pieters 01 Sep '99

01 Sep '99

At 01:14 28/08/99 , Michel Pelletier wrote: >Getting back to to original idea for this whole thing is testing. An >internal heartbeat system is not such a bad thing, in fact there is one >but I don't think it's documented anywhere, it's a hack with zdaemon >anyway. I think this could be handy. Two problems with using this: 1) It prints a damn annoying 'tha-thump' every heartbeat. Fixable, I know. 2) It only runs on Unix. ZDaemon is not used on NT (z2.py line 213: if sys.platform=='win32': Zpid='') -- Martijn Pieters, Web Developer | Antraciet http://www.antraciet.nl | Tel: +31-35-7502100 Fax: +31-35-7502111 | mailto:mj@antraciet.nl http://www.antraciet.nl/~mj | PGP: http://wwwkeys.nl.pgp.net:11371/pks/lookup?op=get&search=0xA8A32149 ------------------------------------------

3 3

XMLDocument appears to leak memory
by Martijn Faassen 31 Aug '99

31 Aug '99

Hi there, I think I've seen an earlier report and I'd like to confirm this. XML Document appears to leak memory pretty badly: * When rendering it with DTML to HTML, Zope's memory use often goes up a few kilobytes. Not all the time, it appears, but a reload often does the trick. * It also appears that doing a DOM manipulation (for instance appendChild) increases Zope's memory use significantly; by a few 10s of k. Now, I'm using some external methods to render and manipulate this document, so I may be introducing some circular references there instead. I'll try to find a simple test case. Zope's memory use is easily driven up by a couple of megabytes in a short time by what I'm doing, which is rather annoying. Anyone has any idea on what may be going on? Regards, Martijn

2 1

Re: [Zope-dev] ZSybaseDA 1.0.1 and MS-SQL (was Re: ANN: ZSybaseDA 1.0.1)
by Anthony Baxter 31 Aug '99

31 Aug '99

>>> Anthony Baxter wrote > I'm attempting to connect from a Linux (RH5.2ish) box using Sybase client > libs from Sybase ASE 11.0.3.3 to MS-SQL 6.5sp3. > > The SQL Method > select count(name) as cnt from sysobjects > > gives the following when you try to do a Test: > > Error, SybaseError: ct_cursor failed > ct_cursor(): user api layer: external error: The connection's capabili ties do not support this type of request. Quick update: It seems that you can't use a cursor under ctsybase (both old and new versions) when talking to MS SQL. The old ZSybaseDA just uses connection.execute()'s results (rather than the DB-SIG interface). It's quite possible that the cursor is being opened with the wrong options or something - I have no idea about the ctsybase C interface (learning Oracle's OCI interface was bad enough). I have a brutally hacked version that goes back to the previous version of ZSybaseDA's use of the db.execute's return results, and it seems to work. What's the best way to deal with this? Maybe have a checkbox on the Properties screen saying 'use a cursor' (default)? (with a note saying that this may be needed to talk to MS-SQL...) Anthony

2 1

Re: [Zope-dev] DA Question...
by Christopher Petrilli 31 Aug '99

31 Aug '99

> Hello, > > I'm planning to write a product which depends on RDBMS access. > > My only concern are those thread-issues... Could a connectionpool (an > object that holds 10 or more open connections) be a way around this ? What are you trying to solve? Either you can thread, or you can't. If you can't handle access from multiple threads, then 100 connections to the database are useless when you can only talk to one SQLMethod at a time. Connection pooling isn't that easy to get right either. Chris -- | Christopher Petrilli Python Powered Digital Creations, Inc. | petrilli(a)digicool.com http://www.digicool.com

3 2

RE: [Zope-dev] Zope and Com : CoInitialize done on each thread by Zserver?
by Brian Lloyd 31 Aug '99

31 Aug '99

Hi Brad, I've been out for the last week, so ignore me if this has been answered already... > I'm working on an ADO DA for Z2. I'll need to do two things > to get this to > work correctly with Zope 2. > > 1. Before win32com is imported, set sys.coinit_flags=0 > 2. In each thread, call CoInitializeEx(COINIT_FREETHREADED) > > I've seen mentioned earlier on this list that Z2 was already calling > CoInitialize, but I can't find it in any .py files. The win32 binary Zope dist. includes a subset of the win32 extensions, but _not_ win32com - that would open up many new cans of worms having to due with COM versions etc. that we don't want to get into (and that Mark is already doing a good job dealing with in his distribution). So, z2 does not try to call CoInitialize currently (and won't anytime soon). Your need to do these things early in the startup code is similar to some things others have needed, and we've been thinking about adding a more general-purpose hook, where Zope will probably be willing try to import a site-specific module very early in the startup process. Then site maintainers will be able to do whatever they need to do (add things to the path, init COM, etc.) without hacking the Zope sources. Your COM problem exposes a new twist, though. If CoInitialize needs to be called for each thread, then the general-purpose early import hook wouldn't quite be enough for you. The site- specific module hook won't make it into 2.0 final anyway, so we'll try to think about this for a future version. It sounds like what we may need is a sort of way to register functions that should be called on thread creation (and probably also destruction). Brian Lloyd brian(a)digicool.com Software Engineer 540.371.6909 Digital Creations http://www.digicool.com

2 1

Re: [Zope-dev] ZSybaseDA 1.0.1 and MS-SQL (was Re: ANN: ZSybaseDA 1.0.1)
by Anthony Baxter 31 Aug '99

31 Aug '99

Update 2: The following patch makes the ZSybaseDA stop using the cursor() of the ctsybase function. This has one adverse effect that I'm aware of: With a cursor, a large query will only fetch max_rows (as defined by the SQL Method) of the result. Without it, it will get all results, then simply truncate the results to max_rows. And one good effect: It works again against MS SQL. Ideally, this should be an option you can choose on a per-DA instance basis, but I gave up trying to untangle the Shared.DC.Connection code enough that I could have an option for only one type of DA. The other approach would be to dive into the Sybase docs to try and find out what magic is needed to make cursors work against MS SQL. I'm not even going to pretend I'm ever going to get the time to do this... Anyway, this patch works for me. (patch also gone to Collector) --- db.py.orig Tue Aug 31 12:29:26 1999 +++ db.py Tue Aug 31 12:28:40 1999 @@ -91,6 +91,12 @@ from time import gmtime, strftime from Shared.DC.ZRDB.THUNK import THUNKED_TM, Surrogate +# set this to 0 if you get errors like +# ct_cursor(): user api layer: external error: The connection's +# capabilities do not support this type of request. +# when connecting to MS SQL or ancient Sybase servers. +UseCursor = 0 + failures=calls = 0 nonselect_desc=[ @@ -162,7 +168,8 @@ calls=calls+1 db=self.db try: - c=self.cursor + if UseCursor: + c=self.cursor self._register() queries=filter(None, map(strip,split(query_string, '\0'))) if not queries: raise 'Query Error', 'empty query' @@ -181,15 +188,21 @@ else: query_string=queries[0] if select_m(query_string) >= 0: - r=c.execute(query_string) - result=c.fetchmany(max_rows) - desc=c.description[0] + if UseCursor: + r=c.execute(query_string) + result=c.fetchmany(max_rows) + desc=c.description[0] + else: + result=db.execute(query_string)[0] + result=result[:max_rows] # gross + desc=db.description[0] else: r=db.execute(query_string) result=[[query_string, str(`r`), calls]] desc=nonselect_desc failures=0 - c.close() + if UseCursor: + c.close() except self.Database_Error, v: messages=[] ertype=v[0]

1 0

ZSybaseDA 1.0.1 and MS-SQL (was Re: ANN: ZSybaseDA 1.0.1)
by Anthony Baxter 31 Aug '99

31 Aug '99

>>> Michel Pelletier wrote > Here is the official ZSybaseDA. Currently, the ZSybaseDA is a level 2 > DA, meaning that it will work with a threaded Zope, but all transactions > with all other level 2 DAs are serialized in the transaction manager. > The ZSybaseDA REQUIRES Zope 2.0! I've grabbed this to try against MS SQL 6.5 (the previous version, in the Contrib area, works ok, but not on Zope2) I'm attempting to connect from a Linux (RH5.2ish) box using Sybase client libs from Sybase ASE 11.0.3.3 to MS-SQL 6.5sp3. The SQL Method select count(name) as cnt from sysobjects gives the following when you try to do a Test: Error, SybaseError: ct_cursor failed ct_cursor(): user api layer: external error: The connection's capabilities do not support this type of request. Traceback (innermost last): File /raid/zope/zope2/lib/python/ZPublisher/Publish.py, line 214, in publish_module File /raid/zope/zope2/lib/python/ZPublisher/Publish.py, line 179, in publish File /raid/zope/zope2/lib/python/Zope/__init__.py, line 201, in zpublisher_exception_hook (Object: testsyb) File /raid/zope/zope2/lib/python/ZPublisher/Publish.py, line 165, in publish File /raid/zope/zope2/lib/python/ZPublisher/mapply.py, line 154, in mapply (Object: manage_test) File /raid/zope/zope2/lib/python/ZPublisher/Publish.py, line 102, in call_object (Object: manage_test) File /raid/zope/zope2/lib/python/Shared/DC/ZRDB/DA.py, line 316, in manage_test (Object: testsyb) File /raid/zope/zope2/lib/python/Shared/DC/ZRDB/DA.py, line 297, in manage_test (Object: testsyb) File /raid/zope/zope2/lib/python/Shared/DC/ZRDB/DA.py, line 401, in __call__ (Object: testsyb) File /raid/zope/zope2/lib/python/Products/ZSybaseDA/db.py, line 219, in query SybaseError: (see above) A subsequent request gives: Error, SybaseError: ct_cursor failed The rollback transaction request has no corresponding BEGIN TRANSACTION. ct_results(): user api layer: external error: This routine cannot be called when the command structure is idle. ct_cursor(): user api layer: external error: The connection's capabilities do not support this type of request. SQL used: select count(name) as cnt from sysobjects Traceback (innermost last): (same as above) Before I dive into this (whimper, whimper), anyone got suggestions? Using sqsh with the above query (and the same connection string) works fine, btw. Anthony

1 0

Zopinion : Wysiwig and "reversible style sheets"
by Boris Borcic 31 Aug '99

31 Aug '99

I've like many been keeping an eye on XML and XSLT. It seems to me, that the high interest in these technologies suffers from an astonishing blind spot : reversibility. XML and XSLT are viewed as the perfect data "tubing", that will finally allow easy integration of multiple data sources. XSLT is a powerful tree transformation language, that seems up to the task to enunciate any transforms between two equivalent XML-dressings of data. I believe a very desirable but completely overlooked feature of output styling, is REVERSIBILITY OF TRANSFORMS. I see two typical forms of uses for such a feature. (a) Wysiwig editing of styled output, with deconstruction and back-propagation of the updates to the store. (b) Networking data stores, again with backpropagation of distributed updates to the distinct mother store of each data item. I believe there may be long-term "second niche" for Zope with (b), and a more immediate opportunity with (a)... At a glance, (a) means opening a new model for web-based data acquisition, one that acknowledges that HTML forms weren't designed to provide superslick click-and-point, and, instead of trying to beat MS IE on its own ground, takes another road : have the app serve model documents that the user can modify with a wysiwig html editor (e.g. Amaya), and PUT back... whereupon the app (e.g. Zope) would parse the modifications and distribute them back where they belong... or return the same page, with red annotations for what doesn't parse. Couple motivational notes : (i) Of course, the design of an extensive "reversible style sheet" language is no small matter. But start in the small : think of the situation where one notices a mistaken digit in a figure in a web page. If the page is automatically generated and styled from a data store, wouldn't it be nice (and shouldn't it be possible !) to tell the system : "update the item from which that digit was obtained" - without further ado (except where security is concerned). (ii) There is a parallel to make, between the Closed/Open Source duality, and the Mono-/Bi-directional stylesheet issue, on the other hand. Bidirectional style-sheets are like open source, since they make it easier for the final consumers of data, to effect changes at the source of the data. (iii) Last week, someone posted the open source announcement of Xanadu/Unadax; from what I could gather at their site, their critique of current web technology parallels the above proposal. (iv) XLST doesn't beat DOM in the heart of many "procedurally minded" developpers; and indeed, the DOM is much more flexible. Bidirectionality is where a declarative language like XSLT could really excel. I write this thinking of the recent praise for XMLDocument; somebody spoke of the simplicity of using DTML for XML styling, as compared to XSL; this means that DTML is currently competing with XSL in zopeland, and there may exist a temptation for Zope development to continue on that lead. What I am saying, is that bidirectionality of transforms (which neither XSLT or DTML currently have) is a better ground to be critical of XSLT, since this is where XSLT's declarative style of programming should be stronger. Boris Borcic

2 3

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

Zope-Dev August 1999