Andrej van der Zee wrote:
* apr_dbd_pvquery is only for string values.
You must use apr_dbd_pvbquery (with a "b") for binary values.
see:
http://apr.apache.org/docs/apr-util/1.3/group___a_p_r___util___d_b_d.html
I tried both versions, but without success. But that was because I did not
pass pointers to float obviously.
* You don't pass a float value directly - %f takes a *pointer* to a float.
O yes, thank you! That did the trick. I definitely missed this in the
documentation. Is it there?
http://apr.apache.org/docs/apr-util/1.3/group___a_p_r___util___d_b_d.html#g19608fa5d518a5121bee23daacc5c230
describes the binary datatypes. Note that they all take pointers, e.g.
APR_DBD_TYPE_FLOAT %f : in, out: float*
* It is best not to call ap_dbd_prepare and ap_dbd_acquire directly.
You should populate your own function pointers at config time using
APR_RETRIEVE_OPTIONAL_FN.
If APR_RETRIEVE_OPTIONAL_FN gives you NULL pointers, that means that
mod_dbd is not loaded.
I have no problems with calling these function directly. If mod_dbd is not
loaded, Apache simply does not start. But it does impose a restriction on
the order that the modules are loaded.
True, these functions still work when your module links directly to mod_dbd - but
APR_RETRIEVE_OPTIONAL_FN is worth using for several reasons:
1) You won't need to load modules in a specific order (as you observed)
2) It lets you return meaningful error messages while processing config
directives, e.g.
if (dbd_acquire_fn == NULL)
return "this directive requires mod_dbd";
-tom-
