Calling Catalog from python script
I'll probably figure this out as soon as I post like last time, but I've been staring at it and can't see my mistake. The following code returns a list of None's: objs = [] for catent in container.Catalog(context.REQUEST): objs.append(container.Catalog.getobject(catent.data_record_id_)) return objs I've checked, and catent is a mybrains instance and catent.data_record_id_ has an increasing number as its value. So why doesn't this work? Also, and this is a better reason for posting this to zope-dev than asking for help is <grin>: why can't I say catent.getobject() That would seem to be a lot more OOish. This is under Zope-2.3.0, by the way. --RDM
"R. David Murray" wrote:
objs = [] for catent in container.Catalog(context.REQUEST): objs.append(container.Catalog.getobject(catent.data_record_id_)) return objs
I've checked, and catent is a mybrains instance and catent.data_record_id_ has an increasing number as its value. So why doesn't this work?
Where did getobject come from? I know about Catalog.data, but I've never seen a getobject() method...
Also, and this is a better reason for posting this to zope-dev than asking for help is <grin>: why can't I say
catent.getobject()
That would seem to be a lot more OOish.
I agree - I'm working with Catalog at the moment, and the whole brain thing confuses the hell out of me :) Richard -- Richard Jones richard@bizarsoftware.com.au Senior Software Developer, Bizar Software (www.bizarsoftware.com.au)
richard@bizarsoftware.com.au wrote:
"R. David Murray" wrote:
catent.getobject()
That would seem to be a lot more OOish.
In 2.3 you can call catent.getObject(). You can pass an optional REQUEST in as an argument, to support lookup via resolve_url rather than restrictedTraverse. -- Steve Alexander Software Engineer Cat-Box limited http://www.cat-box.net
On Wed, 14 Feb 2001, Steve Alexander wrote:
"R. David Murray" wrote:
catent.getobject()
That would seem to be a lot more OOish.
In 2.3 you can call catent.getObject(). You can pass an optional REQUEST in as an argument, to support lookup via resolve_url rather than restrictedTraverse.
Thanks muchly, I didn't see that method in the catalog source when I looked. I forgot to look for the mybrains definition <kicks self>. Howevever, I'm still getting 'None' as the result. If I print out, say, catent.id, I see the correct ID for the object I'm trying to retrieve. It doesn't make sense that this is failing. I must be doing something stupid but I still can't see it. I tried calling getObject both with and without REQUEST as a parameter, with the same result. I guess it's time for some more source spelunking. --RDM
On Fri, 16 Feb 2001, R. David Murray wrote:
Howevever, I'm still getting 'None' as the result. If I print out, say, catent.id, I see the correct ID for the object I'm trying to retrieve.
It doesn't make sense that this is failing. I must be doing something stupid but I still can't see it. I tried calling getObject both with and without REQUEST as a parameter, with the same result.
I guess it's time for some more source spelunking.
And the expedition was a qualified success. It turns out that getObject has one of those nasty unadorned try: except: structures in it. It was masking an authorization error. The auth error is occuring in urestrictedTraverse, and the last lines of my traceback are: File /usr/local/zope/Zope230/lib/python/OFS/Traversable.py, line 190, in unrestr ictedTraverse (Object: ApplicationDefaultPermissions) Unauthorized: 0060175400 0060175400 is the ID of the first object returned by the catalog. Any guesses why this is happening? I get the same result whether I'm anonymous or logged in as a manager. Also, anyone want to guess why getObject uses try/except? I can't off the top of my head think of any reason it should be there. This is 2.3.0, I suppose I should try the new beta just for kicks... --RDM
R. David Murray wrote:
And the expedition was a qualified success. It turns out that getObject has one of those nasty unadorned try: except: structures in it. It was masking an authorization error. The auth error is occuring in urestrictedTraverse, and the last lines of my traceback are:
File /usr/local/zope/Zope230/lib/python/OFS/Traversable.py, line 190, in unrestr ictedTraverse (Object: ApplicationDefaultPermissions) Unauthorized: 0060175400
0060175400 is the ID of the first object returned by the catalog.
Any guesses why this is happening? I get the same result whether I'm anonymous or logged in as a manager.
Also, anyone want to guess why getObject uses try/except? I can't off the top of my head think of any reason it should be there.
This is 2.3.0, I suppose I should try the new beta just for kicks...
Yes, do try the new beta. If this is what I think it is, it is fixed in the latest 2.3, as I submitted the patch that fixed it :-) Are your objects traversed to through an object that does __bobo_traverse__ -- like a ZPatterns Specialist, for example? If so, that's your problem. It's a combination of ZClasses not having a __roles__ attribute, and some security context being lost when going through a __bobo_traverse__. The patch to ZCatalog brains makes it fall back on resolve_url, which works just fine. -- Steve Alexander Software Engineer Cat-Box limited http://www.cat-box.net
On Fri, 16 Feb 2001, Steve Alexander wrote:
This is 2.3.0, I suppose I should try the new beta just for kicks...
Yes, do try the new beta. If this is what I think it is, it is fixed in the latest 2.3, as I submitted the patch that fixed it :-)
Are your objects traversed to through an object that does __bobo_traverse__ -- like a ZPatterns Specialist, for example?
Yes, the items come out of a Specialist. However, upgrading to 2.3.1b1 did not solve the problem. I don't see any changes to getObject.
The patch to ZCatalog brains makes it fall back on resolve_url, which works just fine.
So I changed getObject to wrap the try/except around only the restrictedTraverse call and moved the call to resovle_url outside that, and that seems to have fixed the problem. Thanks, Steve! You might want to look to see where your patch went, though <wry grin>. --RDM
[richard@bizarsoftware.com.au] | Where did getobject come from? I know about Catalog.data, but I've never | seen a getobject() method... It's a method of the brain ;). If you have a data_record_id, you can use getobject() to retrieve the object it represents.
"R. David Murray" wrote:
I'll probably figure this out as soon as I post like last time, but I've been staring at it and can't see my mistake. The following code returns a list of None's:
objs = [] for catent in container.Catalog(context.REQUEST): objs.append(container.Catalog.getobject(catent.data_record_id_)) return objs
I've checked, and catent is a mybrains instance and catent.data_record_id_ has an increasing number as its value. So why doesn't this work?
Also, and this is a better reason for posting this to zope-dev than asking for help is <grin>: why can't I say
catent.getobject()
That would seem to be a lot more OOish.
This is under Zope-2.3.0, by the way.
--RDM
That code looks pretty good to me. Did you try updating the Catalog? Also, what happens if just append catent. Do you get something other than None then? I would assume so, but it might help to see exactly what the meta data is to identify the objects it "should" return. I agree that getobject should be a method of the result item, although implementing it might be a bit tricky to do. I looked into that a while back. Perhaps I should take another look at that... -- | Casey Duncan | Kaivo, Inc. | cduncan@kaivo.com `------------------>
participants (5)
-
Casey Duncan -
Erik Enge -
R. David Murray -
richardï¼ bizarsoftware.com.au -
Steve Alexander