Jonathan Leffler wrote:
Good luck...
Do you need to think of bound variables as 'global', and therefore
incompatible with threaded operation? Or, once a thread binds variables to a
handle, only that thread can use the handle?
I'm trying to provide as much flexibility as possible (if only because
I'm going to be using all this stuff for a large scale project very soon),
so I'm going to avoid imposing any restrictions, except for some
odd, or never/hardly ever used, cases (see below).
The 'bind-as-you-execute' or 'bind-as-you-fetch' model is better suited to
threaded operation, perhaps?
Precisely. At present, the client stubs accumulate the bind
operations, and then pass an indication of the binding (including
the optional type info) over to the apt. thread on fetch(),
where the bindings are detected, and the apt. thread applies
a local bind (solely in order to emulate fetchall_XXX()
behavior wrt bind()), and then returns the resulting bound values
to the client stub. If it weren't for the fetchall_XXX
case, the client stub could just dump the row values into
the bound variables.
The more I think about this, the more I'm convinced
I should just POD a caveat that fetchall_XXX with bind_col()
isn't supported (much like binding multiple variables to a single
column). Why would anyone want to do that anyway?
- Dean