Bug 3164 - SQLx SQL_ThreadQuery Auto-free Handle Optionality
SQLx SQL_ThreadQuery Auto-free Handle Optionality
Status: RESOLVED WONTFIX
Product: AMX Mod X
Classification: Unclassified
Component: Module: MySQL
trunk
PC All
: P4 minor
Assigned To: amxmodx-bugs@alliedmods.net
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-03-14 22:46 PDT by alien
Modified: 2013-07-04 06:23 PDT (History)
3 users (show)

See Also:


Attachments

Description alien 2008-03-14 22:46:57 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
Comment 1 David Anderson [:dvander] 2008-03-14 22:48:13 PDT
I don't see a good reason to do this.  What's your specific use case?
Comment 2 alien 2008-03-14 22:59:09 PDT
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.
Comment 3 joropito 2013-07-04 06:23:00 PDT
You can handle this manually and adding another parameter to handler could broke already compiled plugins.

Note You need to log in before you can comment on or make changes to this bug.