#226 DOUBLE values from MySQL not set to avp by avpops

1.5.x
closed-invalid
modules (454)
5
2009-12-14
2009-12-04
Anonymous
No

it looks like "DOUBLE" is not defined as a valid case in avpops_db.c and as a result avp are unable to be set....
I've removed some of the deployment specific variables from below:

Relevant section of route:
avp_db_query("select x,y,z from db where interstate='$avp(i:200)' group by id","$avp(i:100),$avp(s:cost),$avp(i:400)");
avp_print();

output on debug:
Dec 3 20:38:20 [23959] DBG:avpops:ops_dbquery_avps: query [select x,y,z from db where interstate='0' group by id]
Dec 3 20:38:20 [23959] DBG:core:db_do_raw_query: SYNC-DBG - raw query succesfully executed!
Dec 3 20:38:20 [23959] DBG:core:db_new_result: allocate 48 bytes for result set at 0x784558
Dec 3 20:38:20 [23959] DBG:db_mysql:db_mysql_get_columns: 3 columns returned from the query
Dec 3 20:38:20 [23959] DBG:core:db_allocate_columns: allocate 84 bytes for result columns at 0x7844f0
Dec 3 20:38:20 [23959] DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x784508)[0]=[x]
Dec 3 20:38:20 [23959] DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type
Dec 3 20:38:20 [23959] DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x784518)[1]=[y]
Dec 3 20:38:20 [23959] DBG:db_mysql:db_mysql_get_columns: use DB_DOUBLE result type
Dec 3 20:38:20 [23959] DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x784528)[2]=[z]
Dec 3 20:38:20 [23959] DBG:db_mysql:db_mysql_get_columns: use DB_INT result type
Dec 3 20:38:20 [23959] DBG:core:db_allocate_rows: allocate 336 bytes for result rows and values at 0x784618
Dec 3 20:38:20 [23959] DBG:db_mysql:db_mysql_str2val: converting STRING [x]
Dec 3 20:38:20 [23959] DBG:db_mysql:db_mysql_str2val: converting DOUBLE [0.006400]
Dec 3 20:38:20 [23959] DBG:db_mysql:db_mysql_str2val: converting INT [1]
Dec 3 20:38:20 [23959] DBG:db_mysql:db_mysql_str2val: converting STRING [y]
Dec 3 20:38:20 [23959] DBG:db_mysql:db_mysql_str2val: converting DOUBLE [0.010400]
Dec 3 20:38:20 [23959] DBG:db_mysql:db_mysql_str2val: converting INT [1]
Dec 3 20:38:20 [23959] DBG:db_mysql:db_mysql_str2val: converting STRING [c8a]
Dec 3 20:38:20 [23959] DBG:db_mysql:db_mysql_str2val: converting DOUBLE [1.000000]
Dec 3 20:38:20 [23959] DBG:db_mysql:db_mysql_str2val: converting INT [1]
Dec 3 20:38:20 [23959] DBG:core:db_do_raw_query: SYNC-DBG - SELECT result was stored!
Dec 3 20:38:20 [23959] DBG:avpops:db_query_avp: rows [3]
Dec 3 20:38:20 [23959] DBG:avpops:db_query_avp: row [2]
Dec 3 20:38:20 [23959] DBG:avpops:db_query_avp: row [1]
Dec 3 20:38:20 [23959] DBG:avpops:db_query_avp: row [0]
Dec 3 20:38:20 [23959] DBG:avpops:db_close_query: close avp query
Dec 3 20:38:20 [23959] DBG:core:db_free_columns: freeing result columns at 0x7844f0
Dec 3 20:38:20 [23959] DBG:core:db_free_rows: freeing 3 rows
Dec 3 20:38:20 [23959] DBG:core:db_free_row: freeing row values at 0x784648
Dec 3 20:38:20 [23959] DBG:core:db_free_row: freeing row values at 0x7846a8
Dec 3 20:38:20 [23959] DBG:core:db_free_row: freeing row values at 0x784708
Dec 3 20:38:20 [23959] DBG:core:db_free_rows: freeing rows at 0x784618
Dec 3 20:38:20 [23959] DBG:core:db_free_result: freeing result set at 0x784558
Dec 3 20:38:20 [23959] DBG:core:db_free_result: SYNC-DBG - freeing result!
Dec 3 20:38:20 [23959] INFO:avpops:ops_print_avp: p=0x2b709e908fa8, flags=0x0000
Dec 3 20:38:20 [23959] INFO:avpops:ops_print_avp: id=<400>
Dec 3 20:38:20 [23959] INFO:avpops:ops_print_avp: val_int=<1>
Dec 3 20:38:20 [23959] INFO:avpops:ops_print_avp: p=0x2b709e908f70, flags=0x0002
Dec 3 20:38:20 [23959] INFO:avpops:ops_print_avp: id=<100>
Dec 3 20:38:20 [23959] INFO:avpops:ops_print_avp: val_str=<x / 3>
Dec 3 20:38:20 [23959] INFO:avpops:ops_print_avp: p=0x2b709e908f48, flags=0x0000
Dec 3 20:38:20 [23959] INFO:avpops:ops_print_avp: id=<400>
Dec 3 20:38:20 [23959] INFO:avpops:ops_print_avp: val_int=<1>
Dec 3 20:38:20 [23959] INFO:avpops:ops_print_avp: p=0x2b709e908f10, flags=0x0002
Dec 3 20:38:20 [23959] INFO:avpops:ops_print_avp: id=<100>
Dec 3 20:38:20 [23959] INFO:avpops:ops_print_avp: val_str=<y / 7>
Dec 3 20:38:20 [23959] INFO:avpops:ops_print_avp: p=0x2b709e908ee8, flags=0x0000
Dec 3 20:38:20 [23959] INFO:avpops:ops_print_avp: id=<400>
Dec 3 20:38:20 [23959] INFO:avpops:ops_print_avp: val_int=<1>
Dec 3 20:38:20 [23959] INFO:avpops:ops_print_avp: p=0x2b709e908eb0, flags=0x0002
Dec 3 20:38:20 [23959] INFO:avpops:ops_print_avp: id=<100>
Dec 3 20:38:20 [23959] INFO:avpops:ops_print_avp: val_str=<c8a / 3>
Dec 3 20:38:20 [23959] INFO:avpops:ops_print_avp: p=0x2b709e908e88, flags=0x0000
Dec 3 20:38:20 [23959] INFO:avpops:ops_print_avp: id=<200>
Dec 3 20:38:20 [23959] INFO:avpops:ops_print_avp: val_int=<0>
Dec 3 20:38:20 [23959] INFO:avpops:ops_print_avp: p=0x2b709e908e50, flags=0x0002
Dec 3 20:38:20 [23959] INFO:avpops:ops_print_avp: id=<201>
Dec 3 20:38:20 [23959] INFO:avpops:ops_print_avp: val_str=<CA / 2>
Dec 3 20:38:20 [23959] INFO:avpops:ops_print_avp: p=0x2b709e908e10, flags=0x0002
Dec 3 20:38:20 [23959] INFO:avpops:ops_print_avp: id=<50>

Discussion

    • assigned_to: nobody --> bogdan_iancu
     
    • status: open --> open-invalid
     
  • Hi Komnieve,

    The double values (from DB) are skipped because the AVP (or any other variable in OpenSIPS script) cannot handle double numbers - just simple integers.

    So, a solution for you will be to have the cost as integer number...

    Regards,
    Bogdan

     

  • Anonymous
    2009-12-13

    Ahhh got it,

    I had it initially configured to be integers but was hoping for integration reasons we could use doubles.

    Does the limitation arise from a core module or is it inherent to the way the language was developed?

    Thanks for the response.

     
  • It is related to the fact that the AVP vars cannot handle double - these vars are implemented in core.
    So, the issue is AVP related, not script.

    I will close your bug report - if you fill like, open a feature request.

    Regards,
    Bogdan

     
    • status: open-invalid --> closed-invalid