Re: [Zope-dev] ZSQL Methods from Python?
"Phillip J. Eby" wrote:
At 08:43 AM 9/22/00 -0400, Jim Fulton wrote:
Also, does anyone know of any work done to extend ZSQL Methods to allow stored-procedure calls?
No, but I'd love to see someone tackle it. The semantics of stored procedures varies so widely accross databases, that I doubt that it would be easiliy generalizable. I think, at least for starters, a form of stored procedure support for Oracle would make alot of sense.
Ty and I have put together a Stored Procedure method for Sybase; it requires a minor patch to ZSybaseDA, however, to allow for the status code return. I'm not sure how useful it would be to anyone else, though, since all we ever do with stored procedures is process the return value, and ignore any actual SELECT results.
I think it would be useful. Can you get multiple return values? Jim -- Jim Fulton mailto:jim@digicool.com Python Powered! Technical Director (888) 344-4332 http://www.python.org Digital Creations http://www.digicool.com http://www.zope.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.
At 12:49 PM 9/22/00 -0400, Jim Fulton wrote:
"Phillip J. Eby" wrote:
Ty and I have put together a Stored Procedure method for Sybase; it requires a minor patch to ZSybaseDA, however, to allow for the status code return. I'm not sure how useful it would be to anyone else, though, since all we ever do with stored procedures is process the return value, and ignore any actual SELECT results.
I think it would be useful. Can you get multiple return values?
By "return value", I mean the "return status" code which is an integer returned by the Sybase "RETURN" statement. Sybase also can generate its own, negative-numbered return statuses, which indicate a Sybase error. These error codes can include ones that mean the current transaction has already been aborted. Apart from the "return value", a Sybase stored procedure can execute SELECT's which result in rows being returned. We have never used this capability, so I'm not sure what would need to be done for it to be practical. We ordinarily use stored procedures only to perform inserts, updates, deletes, and other things that only need a integer result if anything. (Eg: get next counter value to assign an object identifier.)
I've started browsing the ZPatterns code, and here are the questions that came up for me while reading PlugsIns.py... Is zope-dev a good place for this? Would somewhere in the ZPatterns wiki be better? The PlugInBase.manage_afterAdd() and manage_beforeDelete() methods dynamically checks if their container has the _addPlugIn() and _removePlugIn() methods before calling them. Could this code be simplified by requiring containers support an add/remove PlugIn interface, with a default do-nothing implementation? The PlugInContainer._addPlugIn() and _removePlugIn() will register a plugin with multiple groups. However _findGroupFor() appears to assume that a plugin is associated with one plugin group. What would be an example of a plugin that registered itself with multiple plugin groups? The PlugInContainer directly accesses the __plugin_kind__ attribute of a plugin. Could we have a plugin.kind() method instead? PlugIns.py patches the Zope ProductContext class to add the _registerPlugInClass method. Could we instead update the Zope implementation to provide a _registerPlugInClass method, that called the ZPatterns product if it was installed?
At 12:07 PM 9/25/00 -0400, Andrew Wilcox wrote:
The PlugInBase.manage_afterAdd() and manage_beforeDelete() methods dynamically checks if their container has the _addPlugIn() and _removePlugIn() methods before calling them. Could this code be simplified by requiring containers support an add/remove PlugIn interface, with a default do-nothing implementation?
Sure, but that would be a change to the Zope core - ZPatterns is intended to be an independent add-on.
The PlugInContainer._addPlugIn() and _removePlugIn() will register a plugin with multiple groups. However _findGroupFor() appears to assume that a plugin is associated with one plugin group. What would be an example of a plugin that registered itself with multiple plugin groups?
There isn't one, AFAIK. The add/remove operations are slightly overengineered Early in the process we thought there'd be a need and that PlugIns would be able to have multiple plug-in kinds. Later on we decided to keep it simple and support only one.
The PlugInContainer directly accesses the __plugin_kind__ attribute of a plugin. Could we have a plugin.kind() method instead?
As Jim likes to say, what problem are you trying to solve? :)
PlugIns.py patches the Zope ProductContext class to add the _registerPlugInClass method. Could we instead update the Zope implementation to provide a _registerPlugInClass method, that called the ZPatterns product if it was installed?
Again, that would be a Zope core change, and ZPatterns is intended to be an independent add-on. If at some later date there is a move to incorporate PlugIns into the core, what you describe would of course make sense. Although in that case, the necessary code would go straight into ProductContext and not be a part of ZPatterns any more.
participants (3)
-
Andrew Wilcox -
Jim Fulton -
Phillip J. Eby