[OpenSIPS-Users] Dispatcher Order SQL DB - version 1.11.5

[Bogdan-Andrei Iancu]

Hi Federico,

Well, it is a good workaround. As a hint, if you do not want to 
sacrifice the "attrs" column for ordering (attributes are really useful 
to have in many usage scenarios), you can better use the "weights" column.

Regards,

Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com

On 18.08.2015 17:11, Federico Edorna wrote:
> In my table there is a priority column! ;) I don't know where did I 
> get that schema... sorry, my mistake.
>
> Now, going back to the workarround (just in case someone has the same 
> issue), since I'm not using the attrs column value in the config file, 
> I will use that column to order the set. To accomplish that, I tried 
> with the following patch in modules/dispatcher/dispatch.c
>
>
> --- /tmp/dispatch.c2015-08-18 10:40:27.461325458 -0300
> +++ ./dispatch.c2015-08-18 10:39:45.941081837 -0300
> @@ -699,7 +699,7 @@
> memset( d_data, 0, sizeof(ds_data_t));
>
> /*select the whole table and all the columns*/
> -if(ds_dbf.query(ds_db_handle,0,0,0,query_cols,0,6,0,&res) < 0) {
> +if(ds_dbf.query(ds_db_handle,0,0,0,query_cols,0,6,&ds_dest_attrs_col,&res) 
> < 0) {
> LM_ERR("error while querying database\n");
> goto error;
> }
>
>
> That is, ds_dbf.query sorts the table using &ds_dest_attrs_col. Now 
> the postgres log shows:
>
> 2015-08-18 10:46:51 ART [9503]: [2-1] LOG:  duration: 0.224 ms 
>  statement: select setid,destination,socket,state,weight,attrs from 
> sbc.dispatcher * order by attrs*
>
> I will try with this (at my own risk...) until we upgrade to 2.x
>
> Thanks!
>
>
> On Tue, Aug 18, 2015 at 8:45 AM, Bogdan-Andrei Iancu 
> <bogdan at opensips.org <mailto:bogdan at opensips.org>> wrote:
>
>     Federico,
>
>     There is no "priority" field in the dispatcher table in 1.11 :
>     http://www.opensips.org/Documentation/Install-DBSchema-1-11#AEN4123
>
>     wrong table ?
>
>     Regards,
>
>     Bogdan-Andrei Iancu
>     OpenSIPS Founder and Developer
>     http://www.opensips-solutions.com
>
>     On 17.08.2015 21:03, Federico Edorna wrote:
>>     Actually the table has the priority column in ver 1.11. Anyway,
>>     thanks for your response Bogdan, I will try to find a workarround
>>     for this version until we upgrade to 2.x.
>>
>>     Thanks & Regards
>>
>>     Federico
>>
>>     On Mon, Aug 17, 2015 at 5:56 AM, Bogdan-Andrei Iancu
>>     <bogdan at opensips.org <mailto:bogdan at opensips.org>> wrote:
>>
>>         Hi Federico,
>>
>>         This is an known issue with the older versions of OpenSIPS
>>         (not being able set an order for the records). In 2.1 this
>>         was solved by having a priority column which dictates the
>>         oder of usage of records.
>>
>>         For versions before 2.1, you have to rely on the oder
>>         provided by DB :(.
>>
>>         Regards,
>>
>>         Bogdan-Andrei Iancu
>>         OpenSIPS Founder and Developer
>>         http://www.opensips-solutions.com
>>
>>         On 14.08.2015 20:49, Federico Edorna wrote:
>>>         Hello Guys,
>>>         I'm using dispatcher module with postgres database. The
>>>         ds_select_dst function in the script file is used like this:
>>>
>>>         ds_select_dst("$(var(ds_set){s.int <http://s.int/>})","8");
>>>
>>>         that is, using "8" algorithm (first entry in set is chosen)
>>>         because I need to use always the same destination in the set
>>>         while it is up. If not, then the backup destination (next in
>>>         the set) is used.
>>>
>>>         The problem I've found is that when the sets are read from
>>>         database (opensips restart or fifo ds_reload), the select
>>>         hasn't a "order" directive  in the sql statement, so the
>>>         order is defined depending of the last tuple update. The
>>>         postgres log shows this when doing a fifo ds_reload:
>>>
>>>         2015-08-14 11:36:53 ART [23684]: [1-1] LOG:  duration: 0.582
>>>         ms  statement: select
>>>         setid,destination,socket,state,weight,attrs from sbc.dispatcher
>>>
>>>         And the syslog & debug=6 shows:
>>>
>>>         DBG:db_postgres:db_postgres_submit_query: 0x7f4344987010
>>>         PQsendQuery(select
>>>         setid,destination,socket,state,weight,attrs from
>>>         sbc.dispatcher )
>>>
>>>         So, any sql update in any column will change the order in
>>>         the set because we don't have the "order by priority" for
>>>         example.
>>>
>>>         Is there any way to use the weight, priority or the id to
>>>         have a fixed order in the set(s) destination?
>>>
>>>
>>>         Many Thanks!
>>>         Federico
>>>
>>>
>>>         _______________________________________________
>>>         Users mailing list
>>>         Users at lists.opensips.org  <mailto:Users at lists.opensips.org>
>>>         http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20150819/802094db/attachment-0001.htm>