how call a ZSQL method from a product instance+work w the results
inside my product i have a method like def manage_draw_PI(self, REQUEST=None): """draw: get the x- and y-coords from database """ self.sql_method = \ sql_method = self.aq_parent['sql_query'] # aquired from container self.sql_result = sql_method.__call__(query=self.sql_query) # query = 'select * from PI' self._p_changed = 1 if REQUEST is not None: management_view='Edit' # tell zope to hilight mgnt tab return self.manage_edit_PraxisIndex_Form(self) else: return sql_query is a sql_method for some GadFly.DA if the line w __call__ is commented out, it works (without function). if not, i get Zope Error Zope has encountered an error while publishing this resource. Error Type: cPickle.PicklingError Error Value: Cannot pickle objects. (a look at source shows: <extension class Acquisition.ImplicitAcquirerWrapper at 00EC5110>) Traceback (innermost last): File C:\PROGRA~1\Zope232\lib\python\ZPublisher\Publish.py, line 223, in publish_module File C:\PROGRA~1\Zope232\lib\python\ZPublisher\Publish.py, line 187, in publish File C:\PROGRA~1\Zope232\lib\python\Zope\__init__.py, line 221, in zpublisher_exception_hook (Object: rki) File C:\PROGRA~1\Zope232\lib\python\ZPublisher\Publish.py, line 175, in publish File C:\PROGRA~1\Zope232\lib\python\Zope\__init__.py, line 235, in commit File C:\PROGRA~1\Zope232\lib\python\ZODB\Transaction.py, line 300, in commit File C:\PROGRA~1\Zope232\lib\python\ZODB\Connection.py, line 375, in commit (Info: (('Products.PraxIndex.RKI', 'PraxisIndex'), '\000\000\000\000\000\000\027N', '')) cPickle.PicklingError: (see above) carefully reading Shared/DC/ZRDB revealed nothing (hey, what is a zbrain and what is it good for?) ------------------------------------------------------------- Who's got only a hammer sees the world as a nail hans augustin (software developer) hans@beehive.de beehive elektronische medien GmbH http://www.beehive.de phone: +49 30 847-82 0 fax: +49 30 847-82 299
Hi. See zopelabs.com for the article of generically calling objects/functions in zope (by casey duncan). Then simply acquire the query and call it. The resultset is easy handable when using result = .... call the query here ...().dictionaries() which will give you a list of dictionaries. * hans <hans@beehive.de> [020312 17:00]:
inside my product i have a method like
def manage_draw_PI(self, REQUEST=None): """draw: get the x- and y-coords from database """ self.sql_method = \ sql_method = self.aq_parent['sql_query'] # aquired from container
self.sql_result = sql_method.__call__(query=self.sql_query) # query = 'select * from PI' self._p_changed = 1 if REQUEST is not None: management_view='Edit' # tell zope to hilight mgnt tab return self.manage_edit_PraxisIndex_Form(self) else: return
(hey, what is a zbrain and what is it good for?)
dunno, i never cared for that and it simply doesn't disturb you. :) Greetings Christian -- Christian Theune - ct@gocept.com gocept gmbh & co.kg - schalaunische strasse 6 - 06366 koethen/anhalt tel.+49 3496 3099112 - fax.+49 3496 3099118 mob. - 0178 48 33 981 reduce(lambda x,y:x+y,[chr(ord(x)^42) for x in 'zS^BED\nX_FOY\x0b'])
Christian Theune wrote:
Hi.
See zopelabs.com for the article of generically calling objects/functions in zope (by casey duncan).
Then simply acquire the query and call it. The resultset is easy handable when using
result = .... call the query here ...().dictionaries() which will give you a list of dictionaries.
* hans <hans@beehive.de> [020312 17:00]:
inside my product i have a method like
def manage_draw_PI(self, REQUEST=None): """draw: get the x- and y-coords from database """ self.sql_method = \ sql_method = self.aq_parent['sql_query'] # aquired from container
self.sql_result = sql_method.__call__(query=self.sql_query) # query = 'select * from PI' self._p_changed = 1 if REQUEST is not None: management_view='Edit' # tell zope to hilight mgnt tab return self.manage_edit_PraxisIndex_Form(self) else: return
Just for the record (can't repeat it too often), used the excellent http://www.zope.org/Members/spinwing/ZSQL_Results i have read also the source files (Shared.DC.ZRDB.Results and related), but it turns out to be obfuscated python (a *real* programmer can program assembler in any language) like a class r() w empty body in the middle of statements and one-lettered identifiers. Whats the use of open source if its hard to understand? FACT IS: result objects can't be pickled which implies can't be made an attribute of a persistent object and live through several transactions. The dictionaries() result however can (and thats all i needed).
(hey, what is a zbrain and what is it good for?) dunno, i never cared for that and it simply doesn't disturb you. :)
Well, part of UNIX understanding is reading M.J.Bach's The Design of the UNIX Operating System, and i'd really would appreciate something similar for Zope. cheers hans ------------------------------------------------------------- Who's got only a hammer sees the world as a nail hans augustin (software developer) hans@beehive.de beehive elektronische medien GmbH http://www.beehive.de phone: +49 30 847-82 0 fax: +49 30 847-82 299
Hi. * hans <hans@beehive.de> [020314 10:40]:
Christian Theune wrote:
Just for the record (can't repeat it too often), used the excellent http://www.zope.org/Members/spinwing/ZSQL_Results i have read also the source files (Shared.DC.ZRDB.Results and related), but it turns out to be obfuscated python (a *real* programmer can program assembler in any language) like a class r() w empty body in the middle of statements and one-lettered identifiers. Whats the use of open source if its hard to understand?
Actually this is a part of zope i really would like to see beeing cleaned up, as i fixed already 3 issues on sqltest, 1 outstanding and most time i don't see a real "strategy" someone had writing this code. And almost all of the sql code looks like this (hundreds of single letter identifiers, about 0 doc strings per class) and making patches over patches on them doesn't make them easier to read, and also not more stable. Hope this will get fixed at least in zope 3 ... :( COMMENT FOR ZC PPL: sqltest.py is f*$@d up very ugly. collector #6 is one proof of that!!!
FACT IS: result objects can't be pickled which implies can't be made an attribute of a persistent object and live through several transactions. The dictionaries() result however can (and thats all i needed).
cool idea ... let me think how one could abuse that ... :)
(hey, what is a zbrain and what is it good for?) dunno, i never cared for that and it simply doesn't disturb you. :)
Well, part of UNIX understanding is reading M.J.Bach's The Design of the UNIX Operating System, and i'd really would appreciate something similar for Zope.
cheers hans
Greetings Christian -- Christian Theune - ct@gocept.com gocept gmbh & co.kg - schalaunische strasse 6 - 06366 koethen/anhalt tel.+49 3496 3099112 - fax.+49 3496 3099118 mob. - 0178 48 33 981 reduce(lambda x,y:x+y,[chr(ord(x)^42) for x in 'zS^BED\nX_FOY\x0b'])
participants (2)
-
Christian Theune -
hans