JCRM <<Pike[at]quick-hacks.co.uk>> wrote:
> This attached patch is only half a solution really, but it at least lets
> you use stored procedures with pike.
Interesting, but I think the right way to implement this - which fits
better into the current API - is to instead extend the result object
with functions like more_results() and next_result(). I.e. the same
result object is used both to page through rows in a single result set
and to page through several result sets.
> Multiple result sets makes mysql a lot more stateful, so you need to be
> much more careful how you handle the Sql.Mysql object and results, and
> using the same object across threads is pretty much a no-no.
If the result object keeps state in the connection then the right way
is to return it through a streaming_query() call instead of
big_query() (or query()).
Then one can always make a wrapper on top of it that reads out all the
result sets at once, so that big_query() can provide a result object
which also implements more_results() and next_result(). That wrapper
would preferably be made on the pike level in the generic
lib/modules/Sql.pmod code so that it can be used as a fallback
implementation for all db backends.
> + static void f_more_results (INT32 args)
> + /* Helper function to detect if a string can be sent in the latin1
> + * encoding. */
/.../
> + static void f_next_result (INT32 args)
> + /* Helper function to detect if a string can be sent in the latin1
> + * encoding. */
/.../
Looks like a bit too much cut'n'paste here.. ;)
|