question about manipulating zcatalog query results
Hello all, I've moved a zope 2.5.1 (python 2.1.3) installation to two newer locations (zope 2.7.4/python 2.3.4 and zope 2.7.5/python 2.3.5) and scripts I have that iterate over zcatalog results using 'for' loops now fail with "global name '_getiter_' is not defined." I'm also unable to take the zcatalog result and manipulate it (split or concatenate instances sent to a list) without getting a "Record objects do not support [whatever action]"--even if I've asigned the result to another list and am operating on that list. ie--I used to be able to say: for row in result: res.append(row.id.split().pop(), row) but now can't, and can't even iterate over the list using a while loop, as the split will fail. I've found some reference to the _getiter_ problem on the forum, but the queries date from nearly a year ago, and there were no fixes at the time (save to wait for 7.4 to come out of beta). Is anyone else experiencing this? Is there a workaround? What am I missing? thanks for any help/advice ira
Ira Sher wrote:
the time (save to wait for 7.4 to come out of beta). Is anyone else experiencing this? Is there a workaround? What am I missing?
Can you paste a real traceback or two? cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Chris, a traceback for a script (testy in this case, called from testyer_html, as I've broken out the problem area and have been trying to work around it) using a for loop on a zcatalog result looks like: * Module ZPublisher.Publish, line 101, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module OFS.DTMLMethod, line 144, in __call__ <DTMLMethod instance at 2b98350> URL: http://www.sarabandebooks.test/testyer_html/manage_main Physical Path:/sarabande/testyer_html * Module DocumentTemplate.DT_String, line 474, in __call__ * Module DocumentTemplate.DT_In, line 626, in renderwob * Module DocumentTemplate.DT_Util, line 198, in eval __traceback_info__: testy * Module <string>, line 1, in <expression> * Module Shared.DC.Scripts.Bindings, line 306, in __call__ * Module Shared.DC.Scripts.Bindings, line 343, in _bindAndExec * Module Products.PythonScripts.PythonScript, line 302, in _exec __traceback_info__: ({'traverse_subpath': [], 'container': <Folder instance at 2b923e0>, 'context': <Folder instance at 2b923e0>, 'script': <PythonScript at /sarabande/testy>}, ('Author', 'id', 'none'), {}, None) * Module Script (Python), line 16, in testy NameError: global name '_getiter_' is not defined There is no call to _getiter_, of course, in the script, but whenever I use any for looping on the results, I get a variation of the above. Any thoughts on this? thanks again, ira On Thu, 31 Mar 2005 12:43:52 +0100, Chris Withers <chris@simplistix.co.uk> wrote:
Ira Sher wrote:
the time (save to wait for 7.4 to come out of beta). Is anyone else experiencing this? Is there a workaround? What am I missing?
Can you paste a real traceback or two?
cheers,
Chris
-- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Ira Sher wrote:
There is no call to _getiter_, of course, in the script, but whenever I use any for looping on the results, I get a variation of the above.
Any thoughts on this?
Hmm, I should have asked this in the first place, but can you post the source code for your test python script? cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Chris, the relevant section of the script looks like this: zcat=context.Catalog if spontype == 'none': results = zcat(meta_type=mtype) else: results = zcat(meta_type=mtype,SB_sponsor_type=spontype) if sorton == 'id': res = [] rest = [] res = list(results) for row in res: rest.append(row.id.split().pop(), row) rest.sort() return rest this keeps garnering the 'global name _getiter_ is not defined under 2.7.5'...as you can see, the results have been transfered to a new list, so I'm not even looping and splitting the original query results (this was originally a much briefer script, but I've broken it down to see where exactly things were hanging up). If I pull the loop, or use a while loop and simply asign values from res to rest, then everything works fine, but as soon as I use that for loop, I get the _getiter_ error, and using split with the while loop (looks like: j = 0 while j < len(res): k = res[j] kk = k.split().pop() rest.append(kk) j = j+1 ) I get AttributeError: split, or in the case of trying to play with the k string pulled from the list (by adding additional text, for example) I get "Record objects do not support concatenation". I just can't see a way to play with the zcat query results without raising an error, and I'm dreadful confused... thanks again for looking into this ira On Apr 1, 2005 12:24 AM, Chris Withers <chris@simplistix.co.uk> wrote:
Ira Sher wrote:
There is no call to _getiter_, of course, in the script, but whenever I use any for looping on the results, I get a variation of the above.
Any thoughts on this?
Hmm, I should have asked this in the first place, but can you post the source code for your test python script?
cheers,
Chris
-- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Ira Sher wrote at 2005-3-31 01:05 -0700:
... I've found some reference to the _getiter_ problem on the forum, but the queries date from nearly a year ago, and there were no fixes at the time (save to wait for 7.4 to come out of beta). Is anyone else experiencing this? Is there a workaround? What am I missing?
I remember to have seen reports in the mailing list -- together with a report that the problem was fixed. -- Dieter
I scoured the archives, and found mention of this problem, and a note by you, Dieter saying it was a problem with the 2.7 beta (this was back in May of 2004) but I can't find any subsequent mention of the issue, and the problem I'm having is on both a 2.7.4 and a 2.7.5 build. thanks ira On Apr 1, 2005 2:10 PM, Dieter Maurer <dieter@handshake.de> wrote:
Ira Sher wrote at 2005-3-31 01:05 -0700:
... I've found some reference to the _getiter_ problem on the forum, but the queries date from nearly a year ago, and there were no fixes at the time (save to wait for 7.4 to come out of beta). Is anyone else experiencing this? Is there a workaround? What am I missing?
I remember to have seen reports in the mailing list -- together with a report that the problem was fixed.
-- Dieter
Ira Sher wrote at 2005-4-1 14:29 -0700:
I scoured the archives, and found mention of this problem, and a note by you, Dieter saying it was a problem with the 2.7 beta (this was back in May of 2004) but I can't find any subsequent mention of the issue
Nobody mentioned it again -- until your report... You may try to remove the "list(...)" wrapping in your code. It should work without. If it does not, file a bug report to "http://www.zope.org/Collectors/Zope". -- Dieter
Dieter, I actually put the list in because one of the last suggestions in the archives to repair the problem had to do with enclosing the assignment in a list. The original code was essentially: if sorton == 'id': res=[(row.id.split().pop(), row) for row in results] res.sort() return res This doesn't work, either, in zope 2.7.4 or 2.7.5 with python 2.3.4 and 2.3.5 respectively, as far as I can see. Thanks for taking a look at things--I'll file a bug report (this is stopping me from migrating a site into 2.7) as you suggested ira On Apr 3, 2005 10:44 AM, Dieter Maurer <dieter@handshake.de> wrote:
Ira Sher wrote at 2005-4-1 14:29 -0700:
I scoured the archives, and found mention of this problem, and a note by you, Dieter saying it was a problem with the 2.7 beta (this was back in May of 2004) but I can't find any subsequent mention of the issue
Nobody mentioned it again -- until your report...
You may try to remove the "list(...)" wrapping in your code. It should work without.
If it does not, file a bug report to "http://www.zope.org/Collectors/Zope".
-- Dieter
Ira Sher wrote at 2005-4-3 13:32 -0700:
... "NameError: global name _getiter_ not defined"...
if sorton == 'id': res=[(row.id.split().pop(), row) for row in results] res.sort() return res
This doesn't work, either, in zope 2.7.4 or 2.7.5 with python 2.3.4 and 2.3.5 respectively, as far as I can see.
Thanks for taking a look at things--I'll file a bug report (this is stopping me from migrating a site into 2.7) as you suggested
The strange thing is that I can do: return [o.id for o in container.Catalog()] without a problem. However, I am still using Zope 2.7.2 -- the version before the last security shakeup... If your script does not need security checks, than my "TrustedExecutables" might help you. It provides "PythonScript"s without any security restrictions -- and especially without the need for "_getiter_". <http://www.dieter.handshake.de/pyprojects/zope> -- Dieter
Dieter, thanks. I'll take a look at that now. The folks at bug collection are unable to reproduce the bug on 2.7.5, though, and so we're trying to determine how else it might be occuring--Products would be my best guess, as the Product list has changed (many are obsolete or simply don't run on 2.7.5 when migrating from 2.5.1 (with products that have been left on since 1.x...ug). The last version I had it running stably on was 2.6.3, locally, and of the several products that have been migrated out since then, PluginIndexes and ZCTextIndex I can't grab from cvs (the versions I have crash the startup) as I get a 4k empty tarball downloading with any browser...don't know if these should be obsolete, too. take care and thanks again for the suggestions ira On Apr 4, 2005 11:48 AM, Dieter Maurer <dieter@handshake.de> wrote:
Ira Sher wrote at 2005-4-3 13:32 -0700:
... "NameError: global name _getiter_ not defined"...
if sorton == 'id': res=[(row.id.split().pop(), row) for row in results] res.sort() return res
This doesn't work, either, in zope 2.7.4 or 2.7.5 with python 2.3.4 and 2.3.5 respectively, as far as I can see.
Thanks for taking a look at things--I'll file a bug report (this is stopping me from migrating a site into 2.7) as you suggested
The strange thing is that I can do:
return [o.id for o in container.Catalog()]
without a problem.
However, I am still using Zope 2.7.2 -- the version before the last security shakeup...
If your script does not need security checks, than my "TrustedExecutables" might help you. It provides "PythonScript"s without any security restrictions -- and especially without the need for "_getiter_".
<http://www.dieter.handshake.de/pyprojects/zope>
-- Dieter
Ira Sher wrote:
migrated out since then, PluginIndexes and ZCTextIndex I can't grab
These both ship as part of Zope, you shouldn't even by trying to install them! cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Chris, absolutely right. I got confused and misinterpreted a behavior I was getting with crashes. I was finding that the Zope instance would fail if I didn't have certain files that were in the 2.7.5 Products folder duped in the instance dir...but as it turned out, it all boiled down to a single product--ZCatalog--that I've now placed an older (2.5.1) version of in the instance Products dir (I get a documentToKeyMap error otherwise). With just that product duped (or not duped, but with the older version replacing the newer one in the 2.7.5 Products folder), everything works fine--no more errors looping catalog requests. I suppose this is odd behavior in itself--I'm pleased the site works again, but I am a bit concerned it can only go forward relying on an earlier version on a product--does this matter if only the instance relies on the use of that Product (ie, if I don't actually swap it out of the 2.7.5 installation itself, but only duplicate it in this instance)? thanks for your help ira On Apr 5, 2005 3:56 AM, Chris Withers <chris@simplistix.co.uk> wrote:
Ira Sher wrote:
migrated out since then, PluginIndexes and ZCTextIndex I can't grab
These both ship as part of Zope, you shouldn't even by trying to install them!
cheers,
Chris
-- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
participants (3)
-
Chris Withers -
Dieter Maurer -
Ira Sher