"weights" was my first choice, but I changed my mind because we were not using "atrrs" column neither. Anyway, I will keep in mind your suggestion.
Many Thanks! On Wed, Aug 19, 2015 at 10:59 AM, Bogdan-Andrei Iancu <[email protected]> wrote: > 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 Developerhttp://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.c 2015-08-18 10:40:27.461325458 -0300 > +++ ./dispatch.c 2015-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 <[email protected]> > 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 Developerhttp://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 <[email protected] >> > 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 Developerhttp://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})","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 >>> [email protected]http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >>> >>> >> >> > >
_______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
