Bugzilla – Bug 3164
SQLx SQL_ThreadQuery Auto-free Handle Optionality
Last modified: 2013-07-04 06:23:00 PDT
Dear AMX MOD X team, would it be possible to add another optional parameter for handler function invoked by SQL_ThreadQuery that would specify whether to release data associated with query handle upon handler function finalization? The parameter could be boolean with default value of "true" - meaning that handle should be freed. "false" would mean to leave handle intact so it can be used somewhere else (i.e. in a set_task called from handler function). "false" would also mean that the developer must take care of releasing handle memory using SQL_FreeHandle. Short demonstration (not tested): <code php> SQL_ThreadQuery(db_tuple, "handler_function", "SELECT * FROM `users`", _, _, false); public handler_function(failstate, Handle:query, error[], errnum, data[], size, Float:queuetime, bool:auto_free) { new task_data[1]; task_data[0] = _:query; set_task(1.0, "some_task", 123, task_data, sizeof(task_data)); return PLUGIN_CONTINUE; } // because auto_free == false, memory allocated to 'query' will not be freed automatically public some_task(task_data[1]) { new Handle:query = Handle:task_data[0]; // do something with query // release memory used by handle SQL_FreeHandle(query); } </code> This shouldn't affect any plugin functionality if 'auto_free' parameter would be the last one and with default value. I hope my explanation is as clear as possible, will be understood and considered. With respect Alien
I don't see a good reason to do this. What's your specific use case?
The case I'm actually dealing with is very similar to one shown in example. I need to display some data to a client's console. The source of data mentioned is SQL server. Assuming that there is no limit to the data, I can't display them "all together" due to possible overflowing of client. Therefore, I have a task which would print only one record a run and recursively running itself again (if there are any rows left in resulset), traversing resulset by 1 row each run. This is the safest way I was able to achieve. There might be other cases where someone'd like just to keep the data outside the handler for later processing, but this is the one crossing my way.
You can handle this manually and adding another parameter to handler could broke already compiled plugins.