Hi Evan, On Thu, Jan 21, 2010 at 10:39:58AM -0500, Evan Jones wrote: > In experimenting with libdrizzle, I ended up being surprised by the > fact that drizzle_query, in the default blocking mode, waits for > some sort of result data to come back from the server. Why does this > occur? Is it needed? It seems to me that drizzle_query should just > send the query, and the result reading functions such as > drizzle_result_buffer should actually wait for data back from the > server.
The reason is so drizzle_query can give an indication of if the query succeed on the server, and if so, should you start reading rows (or was it just a status response). If you don't do it here, you need to call result_read which will do this check for you, and depending on that return code, you would either use the status or read rows. Doing it in query() avoids this extra call. > This would allow me to dispatch a bunch of small queries in > parallel, then use blocking reads to get the results. This would be > somewhat simpler than needing to put it in async mode and do that > myself. This is the goal of the batched query interface, as you note below. > Also, I was surprised that drizzle_query_run and > drizzle_query_run_all call drizzle_result_buffer. I was expecting to > have to do that. This means I can't use the incremental reading > functions with these "helper" routines? I guess this is mostly a > documentation issue. The drizzle+query_run* interface is mostly experiemntal right now, the next step is to rewrite that to be more callback driven. This will given finer grain control, and also be able to build a similar interface as whats there on top. -Eric _______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
