type(sql_search())?
Can anybody tell me what this mysterious "results object" thing actually is? I'm working from within a Zope product, and defining an SQL() method (same as "ZSQLMethod" created within the ZMI). I then call the method and get a "list of results". Okay, that's a list, but what are its elements? Aren't they "class instances"? Why don't they have a __dict__? What *is* this beast, and why isn't it something simple? I was actually trying to forgo the ridiculously cumbersome path of defining a "pluggable brain" with module and class name and passing it to the "advanced management" interface of my ZSQLMethod -- i.e. pretending I'm doing everything through the web. It seems like that really ought not to be necessary in product code. You ought to be able to just slap the wrapper on right in the code, without setting up all that boilerplate, e.g.: class my_wrapper: def __init__(self, sqlres): self.__dict__.update(sqlres.__dict__) my_form = DTMLFile('www/my_form', globals()) def some_method(self, foo): return self.sql_stuff + foo wrapped_results = [my_wrapper(r) for r in sql_search()] However, that "sqlres.__dict__" chokes, because, mysteriously, sqlres doesn't have one. I've had a look at RDB.py, and it sure looks like it ought to have __dict__, but experimentation says no. I thought I'd just run type() on it, and see what Python thinks it is, but that brings up another pet peeve about Zope: Why doesn't type() work correctly in Zope? Or rather, why doesn't it have a repr()? Running debugging code like: raise ValueError("My type is %s!" % repr(type(buggy_object))) returns a Zope traceback page which says: Error Type: ValueError Error Value: My type is!
From the Python command line, of course, this will tell me what the type of the object is, such as:
raise ValueError("%s" % type(a)) Traceback (most recent call last): File "<stdin>", line 1, in ? ValueError: <type 'class'>
but not in Zope. Any help would be much appreciated! Terry -- Terry Hancock ( hancock at anansispaceworks.com ) Anansi Spaceworks http://www.anansispaceworks.com "Python takes the pain out of programming ... ... and Zope puts it back again."
It's likely an instance of a "record" object (as defined in lib/Components/ExtensionClass/src/Record.c). I believe the idea for it not having a __dict__ (snicker) was that there can be many, many of these generated for a single SQL query and thus it saved memory at some point in time. I'm not sure how true that is now. It may still be eminently so. They don't have a __dict__ but they are enumerable. Something like this might work (or something along these lines, I have not tested it): class my_wrapper: def __init__(self, sqlres): d = {} for k in sqlres.__record_schema__.keys(): d[k] = getattr(sqlres, k) self.__dict__.update(d) my_form = DTMLFile('www/my_form', globals()) def some_method(self, foo): return self.sql_stuff + foo wrapped_results = [my_wrapper(r) for r in sql_search()] In any case, I'm not sure what you mean about type() not working against them. I can see their type fine including class and module name if I instantiate one from a Python prompt (to do so is a bit cumbersome because it means you must give it a __record_schema__ attribute, typically just for test purposes an empty dictionary, but it does work). If you mean that you can't see their type from a Python Script or DTML or somewhere, the type builtin is not accessible due to security constraints (this is a FAQ). If you mean that this is from "trusted" code like a Product, and its repr just doesn't render in your browser, it's because you're viewing the rendering of the error as an HTML page, the repr is between pointy brackets, and your browser just won't show it to you because it thinks it's part of the HTML. View the source of the page instead, or use Zope 2.6 and learn to use the error_log feature. - C On Mon, 2002-12-09 at 00:34, Terry Hancock wrote:
Can anybody tell me what this mysterious "results object" thing actually is?
I'm working from within a Zope product, and defining an SQL() method (same as "ZSQLMethod" created within the ZMI). I then call the method and get a "list of results". Okay, that's a list, but what are its elements?
Aren't they "class instances"? Why don't they have a __dict__? What *is* this beast, and why isn't it something simple?
I was actually trying to forgo the ridiculously cumbersome path of defining a "pluggable brain" with module and class name and passing it to the "advanced management" interface of my ZSQLMethod -- i.e. pretending I'm doing everything through the web. It seems like that really ought not to be necessary in product code. You ought to be able to just slap the wrapper on right in the code, without setting up all that boilerplate, e.g.:
class my_wrapper: def __init__(self, sqlres): self.__dict__.update(sqlres.__dict__) my_form = DTMLFile('www/my_form', globals())
def some_method(self, foo): return self.sql_stuff + foo
wrapped_results = [my_wrapper(r) for r in sql_search()]
However, that "sqlres.__dict__" chokes, because, mysteriously, sqlres doesn't have one. I've had a look at RDB.py, and it sure looks like it ought to have __dict__, but experimentation says no.
I thought I'd just run type() on it, and see what Python thinks it is, but that brings up another pet peeve about Zope: Why doesn't type() work correctly in Zope? Or rather, why doesn't it have a repr()? Running debugging code like:
raise ValueError("My type is %s!" % repr(type(buggy_object)))
returns a Zope traceback page which says: Error Type: ValueError Error Value: My type is!
From the Python command line, of course, this will tell me what the type of the object is, such as:
raise ValueError("%s" % type(a)) Traceback (most recent call last): File "<stdin>", line 1, in ? ValueError: <type 'class'>
but not in Zope.
Any help would be much appreciated! Terry
-- Terry Hancock ( hancock at anansispaceworks.com ) Anansi Spaceworks http://www.anansispaceworks.com
"Python takes the pain out of programming ... ... and Zope puts it back again."
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Thanks Chris! On Saturday 07 December 2002 10:39 pm, Chris McDonough wrote:
It's likely an instance of a "record" object (as defined in lib/Components/ExtensionClass/src/Record.c). I believe the idea for it not having a __dict__ (snicker) was that there can be many, many of these generated for a single SQL query and thus it saved memory at some point in time. I'm not sure how true that is now. It may still be eminently so. They don't have a __dict__ but they are enumerable. Something like this might work (or something along these lines, I have not tested it):
Okay -- that makes the code a little easier to understand.
class my_wrapper: def __init__(self, sqlres): d = {} for k in sqlres.__record_schema__.keys(): d[k] = getattr(sqlres, k) self.__dict__.update(d) my_form = DTMLFile('www/my_form', globals())
def some_method(self, foo): return self.sql_stuff + foo
wrapped_results = [my_wrapper(r) for r in sql_search()]
This works, though I actually coded it like: for k in sqlres.__record_schema__.keys(): self.setattr(k, getattr(sqlres, k)) which is a little more streamlined in code but I have no idea how efficient it is.
In any case, I'm not sure what you mean about type() not working against them [...] If you mean that this is from "trusted" code like a Product, and its repr just doesn't render in your browser, it's because you're viewing the rendering of the error as an HTML page, the repr is between pointy brackets, and your browser just won't show it to you because it thinks it's part of the HTML. View the source of the page instead, or use Zope 2.6 and learn to use the error_log feature.
Duh. Yeah, that was the problem -- thank you for pointing this out! Cheers, Terry -- Terry Hancock ( hancock at anansispaceworks.com ) Anansi Spaceworks http://www.anansispaceworks.com
Hi Hancock, --On Sonntag, 8. Dezember 2002 21:34 -0800 Terry Hancock <hancock@anansispaceworks.com> wrote:
Can anybody tell me what this mysterious "results object" thing actually is?
I'm working from within a Zope product, and defining an SQL() method (same as "ZSQLMethod" created within the ZMI). I then call the method and get a "list of results". Okay, that's a list, but what are its elements?
Aren't they "class instances"? Why don't they have a __dict__? What *is* this beast, and why isn't it something simple?
I was actually trying to forgo the ridiculously cumbersome path of defining a "pluggable brain" with module and class name and passing it to the "advanced management" interface of my ZSQLMethod -- i.e. pretending I'm doing everything through the web. It seems like that really ought not to be necessary in product code. You ought to be able to just slap the wrapper on right in the code, without setting up all that boilerplate, e.g.:
from Shared.DC.ZRDB.Results.py: 67 class r(Record, Implicit, brains, zbrains): 68 'Result record class' 69 70 r.__record_schema__=schema 71 for k in Record.__dict__.keys(): 72 if k[:2]=='__': 73 setattr(r,k,getattr(Record,k)) 74 75 # Add SQL Aliases 76 d=r.__dict__ 77 for k, v in aliases: 78 if not hasattr(r,k): d[k]=v 79 80 if hasattr(brains, '__init__'): 81 binit=brains.__init__ 82 if hasattr(binit,'im_func'): binit=binit.im_func 83 def __init__(self, data, parent, binit=binit): 84 Record.__init__(self,data) 85 if parent is not None: self=self.__of__(parent) 86 binit(self) 87 88 r.__dict__['__init__']=__init__ 89 90 self._class=r This result set class is just an inner class definition in a list alike class for the results. Adding a column could be a little bit harder since the column name is stored elsewhere. You should look in the definition of Record and brains to find an interface for this. Regards Tino
participants (3)
-
Chris McDonough -
Terry Hancock -
Tino Wildenhain