[OpenSER-Devel] presence load tests: 1.2.1 vs trunk with mysql

[Victor Gamov]

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