- Zope - Zope lists

[Q] iterating over objects in two's ...
by Darran Edmundson 11 Nov '99

11 Nov '99

I wish to iterate over a number of images, putting 'n' images per row in a table. Something like the following: <table><tr> <dtml-in "objectValues(['Image'])"> <td><img src=<dtml-var id>></td> <dtml-if n_images_in_current_row> </tr> <dtml-if not_last_row> <tr> </dtml-if> </dtml-if> </dtml-in> </table> I take it this isn't batch processing since I want all images rendered in the one table. My guess is to use a temporary variable, increment it during each iteration, and check the value modulus n. Any advice is much appreciated. Cheers, Darran. -- Darran Edmundson [Darran.Edmundson(a)anu.edu.au]

1 0

Re: [Zope] MySQL DA Help Please
by Martin Holz 11 Nov '99

11 Nov '99

Anthony Baxter <anthony(a)interlink.com.au> writes: > >>> chris(a)camp.org wrote > > What the heck does this mean? > > > > File "MySQLdb.py", line 19, in ? > > from _mysql import * > > ImportError: ld.so.1: python: fatal: relocation error: file > > /usr/local/mysql/lib > > /mysql/libmysqlclient.so.6: symbol __udivdi3: referenced symbol not found > > Wild guess - try changing the Setup file so that mysqlmodule.so links > with -lm > > Anthony Maybe it helps, but in recent Linux systems __udivdi3 is defined in glib2 (/lib/libc.so.6). It would help, if you could tell us, which OS you are running. If Linux, which libc-Version? Try "ldd /usr/local/mysql/lib/mysql/libmysqlclient.so.6". Do all libraries exist? "nm <library> |grep udivdi3" tells you, which libraries require and provide the symbol. Martin Holz

1 0

Re: [Zope] ZSQL Cacheing
by Martijn Pieters 11 Nov '99

11 Nov '99

At 03:53 11-11-99 , Rob Page wrote: > > Do the queries i.e. sql.get_skin(username='default') > > cache only for that given set of inputs? Or do they cache > > regardless of the inputs? Because we have seen some evidence that the > > result returned doesn't always change even when the username does and >it _should_ have > > to go look it up again. > >IIRC from earlier investigations and presentations from Jim et al the >cacheing data structure is keyed on the rendered string of SQL that is >sent to the RDBMS. There are probably some zany dynamic SQL queries >that could render the same query string for different input values. If >the rendered string is different then the expected behavior is that the >cache would miss causing Zope to reissue the query to the RDBMS. Yup, caching is keyed on the arguments. -- Martijn Pieters, Web Developer | Antraciet http://www.antraciet.nl | T: +31 35 7502100 F: +31 35 7502111 | mj(a)antraciet.nl http://www.antraciet.nl/~mj | PGP: http://wwwkeys.nl.pgp.net:11371/pks/lookup?op=get&search=0xA8A32149 ---------------------------------------------

1 0

MySQL DA Help Please
by chris＠camp.org 11 Nov '99

11 Nov '99

What the heck does this mean? make[2]: Leaving directory `/export/Zope/lib/python/Products/MySQLdb-0.1.0' make[1]: Leaving directory `/export/Zope/lib/python/Products/MySQLdb-0.1.0' gcc -I/usr/include/mysql -g -O2 -I/usr/local/include/python1.5 -I/usr/local/in clude/python1.5 -DHAVE_CONFIG_H -c ./_mysqlmodule.c ld -G _mysqlmodule.o -L/usr/lib/mysql -lmysqlclient -o _mysqlmodule.so Traceback (innermost last): File "build.py", line 14, in ? import MySQLdb File "MySQLdb.py", line 19, in ? from _mysql import * ImportError: ld.so.1: python: fatal: relocation error: file /usr/local/mysql/lib /mysql/libmysqlclient.so.6: symbol __udivdi3: referenced symbol not found any help would be great, thanks! -chris

2 1

Re: [Zope] Locks?
by Phillip J. Eby 11 Nov '99

11 Nov '99

At 02:47 PM 11/11/99 +1100, Stuart 'Zen' Bishop wrote: > >If you have your lock as a module level variable, I believe it will >work. Either have all instances sharing the same lock or store a dictionary >of locks. This should be fine unless you need to maintain a lock between >Zope restarts in which case your lock could be any object with a known id >in a folder (as only one thread can create the object, and the others fail), >and delete it to unlock. Um, that would work for human-scale locking. (E.g., I want to edit object X, so lock it so others can't). But for locking *within* a transaction, it won't necessarily work as you want. Thread A will create the object, and so will thread B. They both think they own the "lock", so they proceed on. One of them then gets rolled back at commit time due to a ConflictError. If you are only making changes to things in the ZODB, that's fine, since everything is rolled back. But if you're guarding access to say, a file or some other external thing, you can still collide any time up until transaction commit.

2 1

XML/XSL and Word Docs.
by Phil Harris 11 Nov '99

11 Nov '99

Hi all, For those that were interested in the MS Word -> XML and the XML/XSL transformation stuff. http://awesum.ml.uwcm.ac.uk:8080/xml_xsl_share The files are located there but as yet there is no documentation, when I have time I will knock up some docs and put them in the same place. In the meantime take a look at the scripts. HTH Phil Harris phil.harris(a)zope.co.uk

2 1

ZSQL Cacheing
by Rob Page 11 Nov '99

11 Nov '99

> Do the queries i.e. sql.get_skin(username='default') > cache only for that given set of inputs? Or do they cache > regardless of the inputs? Because we have seen some evidence that the > result returned doesn't always change even when the username does and it _should_ have > to go look it up again. IIRC from earlier investigations and presentations from Jim et al the cacheing data structure is keyed on the rendered string of SQL that is sent to the RDBMS. There are probably some zany dynamic SQL queries that could render the same query string for different input values. If the rendered string is different then the expected behavior is that the cache would miss causing Zope to reissue the query to the RDBMS. --Rob

3 2

Re: [Zope] Summary of DB Discussion
by Andrew M. Kuchling 11 Nov '99

11 Nov '99

Phillip J. Eby writes: >At 06:31 PM 11/9/99 -0600, Karl Fast wrote: >Could anyone point out where the "real soon now" is on the site? Every >time I've ever looked at the site it has said that they have no plans to >implement fully ACID transactions, ever. David Axmark, one of the MySQL developers, was at the recent Linux conference in Montreal, and in the paper in the proceedings, it's mentioned that transaction support is on the TODO list. (I think it might not be full transactions, though; I don't have the paper here, but I think there were some simplifications. Will check...) -- A.M. Kuchling http://starship.python.net/crew/amk/ "Jane? Jane, are you... Oh my God." "There is no God. I killed him." -- Cliff Steele meets Black Annis in DOOM PATROL #21.

2 1

RE: [Zope] REMINDER: Keep technical discussions on zope-dev!
by Paul Everitt 11 Nov '99

11 Nov '99

Jonothan wrote: > I have to agree with Don, here. The criteria that 'technical' > discussions > should go to zope-dev is a bit to vague to be meaningful. > Even the distinction > between Zope 'users' and 'developers' is a difficult one, as > every Zope user > is a 'developer' in some sense, even if they're writing only > the most trivial > DTML method. These points, and the others, are certainly valid. I agree that the terms are vague, but I don't think anything will be absolutely clear cut. I'm just trying to follow the community's mandate to structure the deluge. [snip] > What do you think about Don's suggestion to break out the > zope list into > several clearly defined sub-topics (DTML, ZClasses, > databases) instead of > trying to distinguish between 'technical' vs. 'non-technical' > questions? > Unfortunately, I can see this being as difficult to judge. > ("Is this a DTML > question or a ZSQL question?") I'm mainly just interested in > generating some > discussion about possible solutions. This is hard, as the territory was obviously covered before, the community spoke, and we implemented the *loud* call to do something about traffic. Before revisiting the territory, perhaps people that made the original call can pipe in and say what they think. If they're still subscribed to the deluge. :^) Seriously, it isn't too joyous for us to create new mailing lists, find some way to migrate people, do the archives, link them on the website, and handle the subsequent confusion -- especially if it will lead us to the same position. Before wiping the slate clean, let's at least keep in mind how the community came to the current conclusion. --Paul

2 1

Re: [Zope] Summary of DB Discussion
by Karl Fast 11 Nov '99

11 Nov '99

On Wed, Nov 10, 1999 at 09:46:43AM -0500, Phillip J. Eby wrote: > At 06:31 PM 11/9/99 -0600, Karl Fast wrote: > > > > - Despite it's lack of transaction support, it was agreed that MySQL > > (a) is popular > > (b) is very fast and a good choice for sites that do high volume > > queries, but relatively simple and low-volume updates > > (c) will be getting transaction support "real soon now" according > > to the web site > > (d) should have a good, up to date, Zope DA > > > > Could anyone point out where the "real soon now" is on the site? Every > time I've ever looked at the site it has said that they have no plans to > implement fully ACID transactions, ever. This page has a list of things they want to do, broken down into 3 sections: 1. Things that must be done in the real near future 2. Things that have to be done sometime 3. Something we don't have any plans to do http://www.mysql.com/Manual_chapter/manual_TODO.html#TODO Under #1 the first two items are "one way replication" and "transactions" Under #3 there is only one entry: "Transactions with rollback (we mainly do SELECTs, and because we don't do transactions, we can be much quicker on everything else). We will support some kind of atomic operations on multiple tables, though. Currently atomic operations can be done with LOCK TABLES/UNLOCK TABLES but we will make this more automatic in the future." ----------------------------------------------------------------- Karl Fast

4 4