[SR-Users] Wrong Publish status

[Daniel-Constantin Mierla]

I pushed the commit to add the new parameter to the master branch. Let
me know if works as expected.

Cheers,
Daniel


On 01/06/16 12:58, Aleš Šturm wrote:
>
> Excellent,
>
>  
>
> I didn’t think about different db connectors. But, your proposal is
> the best choice. If you are willing to prepare correction I can test
> it. Please let me know.
>
>  
>
> All the best,
>
>  
>
> Ales
>
>  
>
> *From:*Daniel-Constantin Mierla [mailto:miconda at gmail.com]
> *Sent:* Wednesday, June 01, 2016 12:38 PM
> *To:* Aleš Šturm; 'Kamailio (SER) - Users Mailing List'
> *Subject:* Re: [SR-Users] Wrong Publish status
>
>  
>
> Hello,
>
> to have full flexibility here I am thinking of adding a new module
> parameter to set the order-by string when the retrieve_order=1, as it
> may be different for various db connectors. The default will be
> 'priority', which is what is done right now.
>
> That will practically cover also the case of retrieve_order=0, where
> the order by is done on received_time, but for backwards compatibility
> I think it should stay there.
>
> Cheers,
> Daniel
>
> On 01/06/16 12:20, Aleš Šturm wrote:
>
>     Hello,
>
>      
>
>     yes, when retrieve_order=1, then order has to be combination of
>     columns »priority« and »received_time«, because there can be
>     multiple records with the same priority, but with different
>     received_time. And we would like to publish the newest status.
>
>      
>
>      
>
>     My example:
>
>      
>
>     mysql> select id,username,received_time,priority from presentity
>     where username=3915 and event='presence' order by priority desc,
>     received_time desc;        
>
>     | id | username | received_time | priority |
>
>     +----+----------+---------------+----------+
>
>     | 34 | 3915     |    1464775887 |       60 |
>
>     | 33 | 3915     |    1464775876 |       60 |
>
>     | 32 | 3915     |    1464775869 |       40 |
>
>     | 30 | 3915     |    1464775844 |       40 |
>
>     | 26 | 3915     |    1464775811 |       40 |
>
>     | 35 | 3915     |    1464775894 |       20 |
>
>     +----+----------+---------------+----------+
>
>      
>
>     All the best,
>
>     Ales
>
>      
>
>      
>
>     *From:*Daniel-Constantin Mierla [mailto:miconda at gmail.com]
>     *Sent:* Wednesday, June 01, 2016 11:47 AM
>     *To:* Aleš Šturm; 'Kamailio (SER) - Users Mailing List'
>     *Subject:* Re: [SR-Users] Wrong Publish status
>
>      
>
>      
>
>      
>
>     On 01/06/16 10:42, Aleš Šturm wrote:
>
>         Hello,
>
>          
>
>         yes, if the priority is the same, records should be ordered by
>         received_time. Acting in this way, when “presentity” table has
>         more than one record of the same user with equal priority, to
>         watcher would be send Notify message with last received status.
>
>          
>
>         SQL like:
>
>         select * from presentity where username=X and priority=Y order
>         by received_time desc;
>
>          
>
>          
>
>     Well, the priority is not known in advance, query is like:
>
>     select ... from presentity by matching the user and event,
>     ordering either by receive_time when retrieve_order=0 or by
>     priority if retrieve_order=1.
>
>     Here it looks like order by has to be a combination of the two
>     columns.
>
>     Cheers,
>     Daniel
>
>
>
>     -- 
>
>     Daniel-Constantin Mierla
>
>     http://www.asipto.com - http://www.kamailio.org
>
>     http://twitter.com/#!/miconda <http://twitter.com/#%21/miconda> - http://www.linkedin.com/in/miconda
>
>
>
> -- 
> Daniel-Constantin Mierla
> http://www.asipto.com - http://www.kamailio.org
> http://twitter.com/#!/miconda <http://twitter.com/#%21/miconda> - http://www.linkedin.com/in/miconda

-- 
Daniel-Constantin Mierla
http://www.asipto.com - http://www.kamailio.org
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20160602/98c38098/attachment.html>