[OpenSIPS-Devel] Db interface

Matt lehner mlehner at gmail.com
Sun Aug 15 05:15:58 CEST 2010


Your db module can choose to implement or not implement the
fetch_result capability. I believe most modules except mysql (maybe
postgres and oracle?) do not implement the fetch_result capability.

I would answer the second piece of your question, but I don't remember
exactly how that is handled in the db. I do know that if you not
implementing fetch_result, n and res_rows should be the number of
records in the current result. Otherwise the calling function will
have no way to know how many rows were returned.

Matt

2010/8/14 Stanisław Pitucha <viraptor at gmail.com>:
> Hi,
> I had another go at a new module and I'm confused about this
> explanation. What does "passing db_res struct" mean in these contexts:
>
> On 4 August 2010 21:17, Bogdan-Andrei Iancu <bogdan at voice-system.ro> wrote:
>> 1) directly, by passing the db_res struct to the query function - it
> ...
>> 2) piece by piece, after the query is done - you do not pass any db_res
>> to the query function; after the query is done, you use fetch_result()
>
> Does this mean, db_text is not compliant / not complete if it's code is:
>
> --->8---
> int dbt_query(db_con_t* _h, db_key_t* _k, db_op_t* _op, db_val_t* _v,
>         db_key_t* _c, int _n, int _nc, db_key_t _o, db_res_t** _r)
> {
> [...]
>   if ((!_h) || (!_r) || !CON_TABLE(_h))
>   {
>      LM_ERR("invalid parameters\n");
> --->8---
>
> If it fails when `(!_r)`, it seems like you cannot use the second method.
> Or did you mean something else by "passing db_res" - allocating *_r,
> but not _r itself?
> My guess at what I should do is something like this for the query function:
>
> --->8---
> // do the query bits, get back the `cursor`
> if (*_r) {
>   db_allocate_columns(*_r, ...);
>   db_allocate_rows(*_r, ...);
>   .... // fill in the rows and columns
> } else {
>   SOME_CUSTOM_FIELD(_h) = cursor;
> }
> --->8---
>
> Then again this doesn't make much sense to me. If that would be the
> case, why is db_res_t** needed at all? If it's always allocated before
> this function, why is it not db_res_t* instead?
>
>
> Another separate issue I run into lately is, what should be filled in
> the result in the second scenario. If I'm using a database which uses
> only cursors and doesn't know the size of resultset before returning
> it all, what do I do about the db_res->n and db_res->res_rows fields?
> Can they be left not filled? And how does fetch_result signal that
> there are no new results to fetch?
>
> Regards,
> Completely confused,
> Stan
>
> _______________________________________________
> Devel mailing list
> Devel at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
>



More information about the Devel mailing list