- Zope-Dev - Zope lists

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

ANNOUNCE: beehive releases mkproduct
by Mark Pratt 31 Aug '99

31 Aug '99

hello all, we have decided to open source mkproduct which together with skeletons can seriously reduce your time spent building zope products. mkproduct is used extensively at beehive to rapidly build prototypes. do check out our documentation availible in both german and english. get mkproduct at www.zope.de/software/mkproduct this is beehive's way of saying thanks to all the nice people in the zope community! regards, mark, basti, katrin, alex -------------------------------------------------------------- mark pratt (managing director) mark(a)beehive.de beehive elektronische medien GmbH http://www.beehive.de phone: +49 30 847-82 0 fax: +49 30 847-82 299

1 0

DA Question...
by Sascha Matzke 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 ? Sascha -- .-> Sascha Matzke - sascha(a)bespin.de - http://www.bespin.de -. | We want the world and we want it now... | | Jim Morrison | `-- On this earth for 23 years, 321 days <----------------'

1 0

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

30 Aug '99

> Until this issue is resolved, where would you suggest that I place my > call to CoInitializeEX()? > > It has to be called only once, when a thread is created. (I'm CC'ing this to the list, since this trick may be useful to others...) If it were me, I'd try _real_ hard to not have to hack up the medusa code (which is where the actual threads get created), and try to find a sneaky way to get the job done from within your product. Here's one way you could do it (not very pretty, but it should work without requiring hacks to Zope code): (in the .py file of your product) _tmap_={} def ensure_init(): # waaa - make sure CoInitialize has been # called for this thread... id=thread.get_ident() if _tmap_.get(id, None) is not None: # this thread has been done already! return # otherwise we need to do it... win32com.CoInitializeEx(...) _tmap_[id]=1 return ...now you should be able to stick an ensure_init() call into your code before you start messing with COM, and the Right Thing ought to happen. It adds a little overhead, but in most cases you could probably streamline this further depending on how your code looks. Hope this helps! Brian Lloyd brian(a)digicool.com Software Engineer 540.371.6909 Digital Creations http://www.digicool.com

1 0

E-Market
by Scott Robertson 30 Aug '99

30 Aug '99

Has anyone else been having problems running E-Market under Zope 1.10.3? Is there an update? --------------------------------------------------- - Scott Robertson Phone: 714.972.2299 - - CodeIt Computing Fax: 714.972.2399 - - http://codeit.com - ---------------------------------------------------

4 5

Persistence
by Paul Prescod 30 Aug '99

30 Aug '99

I think that this: http://www.zope.org/Documentation/Reference/ObjectPublishingIntro is out of date, right? BoboPOS no longer has "PickleDictionary". It would be great if this document could be updated with a message: "this info is a little out of date. Please see blah." Zope really doesn't like what I came up with through hacking around: def doit( state="Texas", city="Dallas"): connection = Globals.DB.open() states=[] connection.root()["abc"]="def" return "foo" Paul Prescod

5 5