[OpenSER-Devel] presence load tests: 1.2.1 vs trunk with mysql
Victor Gamov
vit at lipetsk.ru
Tue Jul 24 18:02:20 CEST 2007
Henning Westerholt wrote:
> On Friday 20 July 2007, Victor Gamov wrote:
>> [..] For db_mysql_fetch result() when nrows==0 function do nothing
>> and return 0. But in this situation if user makes SELECT-like
>> query and then call db_mysql_fetch_rows() with nrows=0 no
>> mysql_store_result() called and it wrong because "you _must_ call
>> mysql_store_result() or mysql_use_result() for every statement that
>> successfully retrieves data"
>> (http://dev.mysql.com/doc/refman/5.1/en/mysql-store-result.html)
>>
>> And it's really strange don't get any data and call
>> db_mysql_fetch_rows() with nrows=0 after SELECT-like query
>>
>> Also there are no problems or "any notable performance degradation
>> if you call mysql_store_result() in all cases".
>>
>> So we can use nrows to realize different behavior for
>> db_mysql_fetch_rows():
>>
>> -- nrows == 0 -- get complete result set. If called after non
>> SELECT-like query it will call mysql_store_result() and
>> mysql_field_count() and return 0
>>
>> -- nrows > 0 -- get result set and return nrows lines only
>>
>> -- if we want to fetch zero rows then we can use nrows < 0 (now
>> looks like wrong parameter value), call mysql_store_result() and
>> mysql_free_result() and return 0.
>
> Hello Victor,
Hi Henning!
> i changed the mysql db API to use the same behaviour as the
> postgresql driver. In my opinion this is the "correct" behaviour of
> the fetch_result function from the API point of view and matches the
> user expectations:
>
> - nrows == 0 - don't return anything because the API user want zero
> rows - nrows == n (for n <= number of rows in query) - return n rows
> - nrows == n (for n > number of rows in query) - return number of
> rows in query - nrows < 0 - return a error because the API is used
> wrong
>
> The raised issues about the memory leaks should now be fixed in mysql
> and postgresql. It makes now sense to call fetch_result after a "non
> select" query. In order to fetch rows you need some rows to work
> with. :-)
>
> A behaviour like you drafted above would only cause confusion, IMHO.
I see your point of view.
But now we have two similar functions.
db_mysql_store_result() is also only one function using many functions
from res.c
My main idea is has only one function to make similar job and remove
unnecessary code from res.c
So, I think that fetch_result() API is still usable when it uses
following approach:
nrows == 0 -- return all rows if it was SELECT-like query. it's frequent
way to use 0 to say "all" when you have not idea about how much (rows)
will be returned. Module must be ready to process whole result set.
> - nrows == n (for n <= number of rows in query) - return n rows -
> nrows == n (for n > number of rows in query) - return number of rows
> in query
Yes, because module ready to process at least nrows rows.
nrows < 0 -- user don't want to process any rows so don't return it.
(for mysql) At any case we must call mysql_store_result().
(see at http://dev.mysql.com/doc/refman/5.1/en/mysql-store-result.html)
We also must call mysql_field_count() to know whether a statement should
return a result set if we need it.
We also must call mysql_free_result() to free memory allocated by
mysql_store_result() (see at
http://dev.mysql.com/doc/refman/5.1/en/mysql-free-result.html)
--
CU,
Victor Gamov
More information about the Devel
mailing list