August 1999 - Zope-Dev

Re: [Zope-dev] Zope idea
by Christopher Petrilli 25 Aug '99

25 Aug '99

> bChristopher Petrilli wrote: >> >> It did have something that linked to a DTML reference guide... the reality >> is that all of these things are great ideas, but we've got to get the core >> documentation done first... patches are as always welcome :-) > > What I meant to say is: if you put in a hook, it will tend to get filled > in more quickly than if you wait to assemble the documentation and then > build the hook. Especially in an OSS project...but I understand that it > is hard to find time even to put in the hook. We're all under the gun in > our various ways. This will probable come as we restructure the UI somewhat, but right now it'd be a new feature, and no new features go into 2 at this point. > Maybe you can help me in the meantime. What are the three lines of > magical invocations that I need to put in my code to persistently store > data in the POS. BoboPOS.PickleDictionary doesn't work anymore. The functionality of the BoboPOS.PickleDicitionary doesn't exist any more in its old functionality. Instead you create a connection to the database and grab the root object, and traverse from there. You should check out the UML model of the database, this would provide a lot of information on how it really works underneath. http://www.zope.org/Documentation/Models/ZODB Chris -- | Christopher Petrilli Python Powered Digital Creations, Inc. | petrilli(a)digicool.com http://www.digicool.com

1 0

Re: [Zope-dev] Zope idea
by Christopher Petrilli 25 Aug '99

25 Aug '99

> I love zope. I love DC. Python rules. etc. > > I also think that a little bit of context-sensitive Zope online help > would go a long way. Even if it mostly consisted of URLs to the zope.org > site...I propose that every management screen should have a "help" page. > Even if it would be empty for a while until they were all filled in... It did have something that linked to a DTML reference guide... the reality is that all of these things are great ideas, but we've got to get the core documentation done first... patches are as always welcome :-) Chris -- | Christopher Petrilli Python Powered Digital Creations, Inc. | petrilli(a)digicool.com http://www.digicool.com

2 1

Zope idea
by Paul Prescod 25 Aug '99

25 Aug '99

I love zope. I love DC. Python rules. etc. I also think that a little bit of context-sensitive Zope online help would go a long way. Even if it mostly consisted of URLs to the zope.org site...I propose that every management screen should have a "help" page. Even if it would be empty for a while until they were all filled in... Paul Prescod

1 0

Product initialization.
by Andreas Kostyrka 25 Aug '99

25 Aug '99

Hi! I've been wondering if there is a way to specify the initialisation order of products? Or is there some defined order already? This would be important for Products that enhance existing Products. (For this scenario, a function "Require_Product(name)" would be most beneficial.) Andreas -- Andreas Kostyrka | andreas(a)mtg.co.at phone: +43/1/7070750 | phone: +43/676/4091256 MTG Handelsges.m.b.H. | fax: +43/1/7065299 Raiffeisenstr. 16/9 | 2320 Zwoelfaxing AUSTRIA

2 3

XML Document appendChild questions
by Martijn Faassen 24 Aug '99

24 Aug '99

Hi there, I've been experimenting with manipulating XML documents in Zope. At first, it seemed to work: I made an XML document called 'testdoc' with the following content: <?xml version="1.0"?> <list> <li>Zero</li> <li>One</li> <li>Two</li> <li>Three</li> </list> And I made another one called 'someElement' with the following content: <?xml version="1.0"?> <li>Another list item</li> Then I made a DTML method called 'testInsert' (actually I'm appending), doing the following:   <p>Done insertion</p>  This indeed adds the new element to the <list> in the testdoc. However, the <li>Another list item</li> disappears from someElement! Is this what should happen? A clue can be found in the XML Document source (Node.py): def appendChild(self, newChild): """ Adds the node newChild to the end of the list of children of this node. If the newChild is already in the tree, it is first removed. """ But in this case 'newChild' is in *another* tree and it is removed as well. Is this intentionally? It seems as if it would be difficult to build trees now, or am I doing something wrong and shouldn't I use XML Documents for XML fragments that I want to insert? I think it may in fact be hard to determine if a cross-tree append is taking place, efficiently at least; right now it is only checked if the newChild to be inserted has a parentNode at all (and removes it from that parent node if so). Regards, Martijn

4 8

Status of mod_pcgi?
by Andy Dustman 24 Aug '99

24 Aug '99

What is the status of mod_pcgi nowadays? The version I have (from June 20 or so) seems to work, but it does not work in conjunction with mod_rewrite. <light bulb>Since I can't rewrite URLs relative to the mount point, can I move the mount point to /?</light bulb> The answer is: Yes. That may well solve my major problem, while creating a new one. -- andy dustman | programmer/analyst | comstar.net, inc. telephone: 770.485.6025 / 706.549.7689 | icq: 32922760 | pgp: 0xc72f3f1d

1 0

zope.org
by Paul Prescod 24 Aug '99

24 Aug '99

I'm looking for a "search" button on www.zope.org. Didn't I see one there at one point? Paul Prescod

3 2

RE: [Zope-dev] Product initialization.
by Michel Pelletier 24 Aug '99

24 Aug '99

> -----Original Message----- > From: Andreas Kostyrka [mailto:andreas@mtg.co.at] > Sent: Tuesday, August 24, 1999 2:40 PM > To: Robin Becker > Cc: zope-dev(a)zope.org > Subject: Re: [Zope-dev] Product initialization. > > > On Tue, 24 Aug 1999, Robin Becker wrote: > > > In article > <Pine.LNX.4.10.9908241833460.3968-100000(a)gatekeeper.zwax.mtg. > > co.at>, Andreas Kostyrka <andreas(a)mtg.co.at> writes > > >Hi! > > > > > >I've been wondering if there is a way to specify the > initialisation order > > >of products? Or is there some defined order already? > > > > > >This would be important for Products that enhance existing > Products. > > >(For this scenario, a function "Require_Product(name)" > would be most > > > beneficial.) > > > > > what's wrong with "import name"? > Well, does it work this way? ;) > (if so, I've just again proved that I classify in "dummy users") > It is safe to import something if it is allready imported. Python will not 'reimport' the module, it will just use the allready imported one. This removes the need for any kind of dependancy type method. Thank Guido. -Michel > Andreas > -- > Andreas Kostyrka | andreas(a)mtg.co.at > phone: +43/1/7070750 | phone: +43/676/4091256 > MTG Handelsges.m.b.H. | fax: +43/1/7065299 > Raiffeisenstr. 16/9 | 2320 Zwoelfaxing > AUSTRIA > > > > _______________________________________________ > Zope-Dev maillist - Zope-Dev(a)zope.org > http://www.zope.org/mailman/listinfo/zope-dev > > (To receive general Zope announcements, see: > http://www.zope.org/mailman/listinfo/zope-announce > > For non-developer, user-level issues, > zope(a)zope.org, http://www.zope.org/mailman/listinfo/zope ) >

2 1

Solid DA patches to handle closed conns
by Andrew M. Kuchling 24 Aug '99

24 Aug '99

Last month I reported that the Solid DA choked when the database server closed the connection on it. Today I looked into it and have some patches (included below); they fix some fairly serious problems, but more still remain. It turns out that ZSolidDA/db.py actually had code to reopen closed connections, but it was never triggered because an except statement used the wrong exception object. Fixing this slip exposed worse problems than the original typo. The first and most critical problem is that when you free a Statement object whose database connection has been closed, you get a core dump. This doesn't seem to be the DA's fault, but rather stems from the libraries in Solid 2.3. I couldn't fix the core dump, so instead the patch rearranges ZSolidDA/db.py to only create self.stmt when it's required, and doesn't copy self.stmt into a local variable, because the statement object might change along the way if .connect() gets called. The second fix is to the C module; the _dealloc() routine for Connection objects raises an exception if there's an error on the SQLDisconnect(), including if the connection was already closed. The patch to pysql.c suppresses the exception if it was a connection-related error. The patches seem to work in my tests, but my findings cast an extremely disturbing light on the stability of Solid's libraries. -- A.M. Kuchling http://starship.python.net/crew/amk/ Advertising reaches out to touch the fantasy part of people's lives. And you know, most people's fantasies are pretty sad. -- Frederik Pohl, _The Way The Future Was_ *** db.py 1999/08/24 16:03:40 1.1 --- db.py 1999/08/24 18:46:50 *************** *** 97,102 **** --- 97,104 ---- + import sql from sql import SQLConnection, SQLDataSources, SQLDescribeCol, SQLExecDirect from sql import SQLFetch, SQLFreeStmt, SQLGetString, SQLNumResultCols + from sql import SQLDisconnect from sql import SQLSetConnectOption, SQLTables, SQLTransact, SQL_AUTOCOMMIT from sql import SQL_AUTOCOMMIT_OFF, SQL_BIGINT, SQL_BINARY, SQL_BIT, SQL_CHAR *************** *** 177,185 **** self._connect() def _connect(self): self.connection=c=apply(SQLConnection, self._connection_info) try: SQLSetConnectOption(c,SQL_AUTOCOMMIT,SQL_AUTOCOMMIT_OFF) except: pass # Oh well - self.stmt=c() def _apply(self, f, args): --- 179,192 ---- self._connect() + def _connect(self): + if hasattr(self, 'connection'): + try: + del self.stmt + del self.connection + except: pass self.connection=c=apply(SQLConnection, self._connection_info) try: SQLSetConnectOption(c,SQL_AUTOCOMMIT,SQL_AUTOCOMMIT_OFF) except: pass # Oh well def _apply(self, f, args): *************** *** 187,198 **** # Checks for stale connections. try: return apply(f, args) ! except error, v: try: tb=sys.exc_traceback state, native, mess = v if state[:2]=='08': ! # Hm, spells like a connection failure. # Let's connect and try again. self._connect() return apply(f, (self.stmt, ) + args[1:] ) raise error, v, tb --- 194,208 ---- # Checks for stale connections. try: return apply(f, args) ! except (error, sql.error), v: try: tb=sys.exc_traceback state, native, mess = v if state[:2]=='08': ! # Hm, smells like a connection failure. # Let's connect and try again. self._connect() + # _connect() creates a new value of self.stmt, so + # we need to use args with the new value of self.stmt. + self.stmt = self.connection() return apply(f, (self.stmt, ) + args[1:] ) raise error, v, tb *************** *** 200,203 **** --- 210,214 ---- def table_info(self): + self.stmt = self.connection() self._apply(SQLTables,(self.stmt, None, None, None, 'TABLE')) r=[] *************** *** 212,223 **** def tables(self, Qualifier=None, Owner=None, Name=None, Type=None, rdb=1): self._apply(SQLTables,(self.stmt, Qualifier, Owner, Name, Type)) return self.query(rdb=rdb) def query(self, src=None, max_rows=99999999, rdb=1): - stmt=self.stmt self._register() try: if src is not None: r=filter(strip,split(src,'\0')) if not r: raise ValueError, 'null sql' --- 223,235 ---- def tables(self, Qualifier=None, Owner=None, Name=None, Type=None, rdb=1): + self.stmt = self.connection() self._apply(SQLTables,(self.stmt, Qualifier, Owner, Name, Type)) return self.query(rdb=rdb) def query(self, src=None, max_rows=99999999, rdb=1): self._register() try: if src is not None: + self.stmt = self.connection() r=filter(strip,split(src,'\0')) if not r: raise ValueError, 'null sql' *************** *** 225,230 **** res=None for s in r: ! self._apply(SQLExecDirect,(stmt,s)) ! status, ncol = SQLNumResultCols(stmt) if ncol: if res is not None: --- 237,242 ---- res=None for s in r: ! self._apply(SQLExecDirect,(self.stmt,s)) ! status, ncol = SQLNumResultCols(self.stmt) if ncol: if res is not None: *************** *** 237,247 **** return res ! self._apply(SQLExecDirect,(stmt,src)) ! except error, v: state, native, mess = v raise error, "%s (%s)" % (mess, state) ! status, ncol = SQLNumResultCols(stmt) if ncol==0: if rdb: return "x\n8s\n" --- 249,260 ---- return res ! self._apply(SQLExecDirect,(self.stmt,src)) ! except KeyError, v: state, native, mess = v raise error, "%s (%s)" % (mess, state) ! ! status, ncol = SQLNumResultCols(self.stmt) if ncol==0: if rdb: return "x\n8s\n" *************** *** 254,258 **** binary_flags=[0]*ncol for i in range(ncol): ! status, name, tp, prec, scale, nullable=SQLDescribeCol(stmt,i+1) names[i]=name if prec < 1: prec=8 --- 267,271 ---- binary_flags=[0]*ncol for i in range(ncol): ! status, name, tp, prec, scale, nullable=SQLDescribeCol(self.stmt,i+1) names[i]=name if prec < 1: prec=8 *************** *** 269,276 **** r.append(join(row,'\t')) ! status=SQLFetch(stmt) while status==SQL_SUCCESS: for i in range(ncol): ! v=SQLGetString(stmt,i+1,binary_flags[i]) if rdbdefs[i]=='t': if find(v,'\\') >= 0: v=join(split(v,'\\'),'\\\\') --- 282,289 ---- r.append(join(row,'\t')) ! status=SQLFetch(self.stmt) while status==SQL_SUCCESS: for i in range(ncol): ! v=SQLGetString(self.stmt,i+1,binary_flags[i]) if rdbdefs[i]=='t': if find(v,'\\') >= 0: v=join(split(v,'\\'),'\\\\') *************** *** 283,305 **** for i in indexes: rd[names[i]]=row[i] r.append(rd) ! status=SQLFetch(stmt) ! SQLFreeStmt(stmt, SQL_CLOSE); if rdb: r=join(r,'\n')+'\n' return r def columns(self, table_name): - stmt=self.stmt try: self._apply(SQLExecDirect, ! (stmt, 'select * from %s where 1=2' % table_name)) except error, v: state, native, mess = v raise error, "%s (%s)" % (mess, state) ! status, ncol = SQLNumResultCols(stmt) r=[] standard_type=tpnames.has_key for i in range(ncol): ! status, name, tp, prec, scale, nullable=SQLDescribeCol(stmt,i+1) if standard_type(tp): tp=tpnames[tp] else: tp="Non-standard type %s" % tp --- 296,317 ---- for i in indexes: rd[names[i]]=row[i] r.append(rd) ! status=SQLFetch(self.stmt) ! SQLFreeStmt(self.stmt, SQL_CLOSE); if rdb: r=join(r,'\n')+'\n' return r def columns(self, table_name): try: self._apply(SQLExecDirect, ! (self.stmt, 'select * from %s where 1=2' % table_name)) except error, v: state, native, mess = v raise error, "%s (%s)" % (mess, state) ! status, ncol = SQLNumResultCols(self.stmt) r=[] standard_type=tpnames.has_key for i in range(ncol): ! status, name, tp, prec, scale, nullable=SQLDescribeCol(self.stmt,i+1) if standard_type(tp): tp=tpnames[tp] else: tp="Non-standard type %s" % tp *************** *** 308,312 **** 'Nullable': nullable and 'with Null' or ''}) ! SQLFreeStmt(stmt, SQL_CLOSE); return r --- 320,324 ---- 'Nullable': nullable and 'with Null' or ''}) ! SQLFreeStmt(self.stmt, SQL_CLOSE); return r *** /tmp/ZSolidDA/src/pysql.c Mon Jan 11 11:43:17 1999 --- pysql.c Tue Aug 24 14:41:17 1999 *************** *** 119,124 **** UNLESS(SQLDisconnect(self->connection) == SQL_SUCCESS && SQLFreeConnect(self->connection) == SQL_SUCCESS) ! PyErr_SetString(PyExc_SQLError, ! "error in SQL connection destructor"); } PyMem_DEL(self); --- 119,141 ---- UNLESS(SQLDisconnect(self->connection) == SQL_SUCCESS && SQLFreeConnect(self->connection) == SQL_SUCCESS) ! { ! char state[6]; ! SDWORD native; ! char mess[SQL_MAX_MESSAGE_LENGTH]; ! SWORD lmess; ! ! SQLError(SQLEnv, self->connection, SQL_NULL_HSTMT, ! state,&native, ! mess,SQL_MAX_MESSAGE_LENGTH-1,&lmess); ! ! /* Only raise an exception if the state code doesn't begin ! with '08'; '08' means a connection error, and we don't ! care about connection errors when we're *closing* a connection. ! */ ! if (state[0]=='0' && state[1] == '8') ! { ! PyErr_Clear(); ! } ! } } PyMem_DEL(self);

1 0

Re: [Zope-dev] CatalogAware must come before ObjectManager
by Andreas Kostyrka 24 Aug '99

24 Aug '99

On Thu, 5 Aug 1999, Michel Pelletier wrote: > It is possible, but only from python, and it is a *real* hack. Doing > this is completely unsupported. I might get shot for revealing the > technique. Well, so it may be well, that I'm far far away on the other side of the big pond ;) Actually, if you need this, I might send you an image of my person, so you can print it out and play Darts. But then, perhaps I should just write a special Emacs mode for editing python source, and enforce it's usage at Digital Creations: As a special feature, this mode would treat lines the contain the keyword "class" as readonly. Yep. And if you want to change the base classes afterwards, you just delete the .py file and type it from the beginning. > Given a Product called 'YourProduct' that contains a Zclass called > 'YourZClass' that you want to 'rebase', first, create a temporary ZClass > called 'TempZClass' in the same product. 'TempZClass' should be built > with the new order or types of subclasses that you want 'YourZClass' to > have. Note that 'TempZClass' need not have anything in it, it just > needs to subclass the right classes. > > Shut down Zope, run python1.5.2 in your lib/python directory, and > execute the following code: > > >>> import Zope > >>> p = Zope.app().Control_Panel.Products.YourProduct > >>> p > <Product instance at 849de28> > >>> p.YourZClass._setBasesHoldOnToYourButts(p.TempZClass._zbases[1:]) > >>> get_transaction().commit() Well, install the attached zc.py in your Externals directory. Add external methods zc_copybases and zc_show (mapped to zc.py/copybases and zc.py/show) somewhere in your ZOPE. For demonstration I assume it's in your root folder, and your zope server is called http://myzope/. Well, then use your browser to visit the following URLs (this does more or less exactly what the above python magic does): http://myzope/zc_show?zclass=YourZClass&product=YourProduct http://myzope/zc_show?zclass=TempZClass&product=YourProduct This shows you the baseclasses of the two Z classes. http://myzope/zc_copybases? srczclass=TempZClass&srcproduct=YourProduct& dstzclass=YourZClass&dstproduct=YourProduct (This should be a one line URL.) This does the voodoo magic above. And completly without shutting down your ZOPE, and it does even comment the transaction nicely. (Interesting question if it is undoable.) And yes, the attached file is twice unsupported ;) 1.) The voodoo is not supported by Digital Creations, so it may change at any time. 2.) The external module is not supported by MTG, as its voodoo coefficient is to high. Andreas -- Andreas Kostyrka | andreas(a)mtg.co.at phone: +43/1/7070750 | phone: +43/676/4091256 MTG Handelsges.m.b.H. | fax: +43/1/7065299 Raiffeisenstr. 16/9 | 2320 Zwoelfaxing AUSTRIA

1 0