[sr-dev] pua module db query bug

[Daniel-Constantin Mierla]

On 12/10/14 09:56, Juha Heinanen wrote:
> Juha Heinanen writes:
>
>> how should this be fixed?  is it enough to always add etag value to the
>> query or should also pres_uri be added just in case etags for different
>> pres_uris would match?  or perhaps the best fix would be to skip the
>> query altogether in send_publish if etag is null?
> i tried the latter in pua/send_publish:
>
> 	if (dbmode==PUA_DB_ONLY)
> 	{
> 		if (publ->etag) {
> 			memset(&dbpres, 0, sizeof(dbpres));
> 			dbpres.pres_uri = &pres_uri;
> 			dbpres.watcher_uri = &watcher_uri;
> 			dbpres.extra_headers = &extra_headers;
> 			presentity = get_record_puadb(publ->id, publ->etag,
> 						      &dbpres, &res);
> 		}
>
> then also the initial publish for the second pres_uri was generated
> correctly without sip-if-match header.  however, now when 200 ok with
> sip-etag header was received from presence server, pua did not insert
> second record to pua table, but updated etag of the existing record of
> the other pres_uri!
>
> looks to me that pua module is pretty badly broken and i'm the first
> ever user who tries it in db_mode=2.
Haven't used it in db_mode=2, but given that pua is an user-agent 
emulator, it is a matter of interaction from other modules as well. So 
far, the main usage in my side is for publishing dialog-info states, 
which works very well.

I had in mind that presence modules needed always to keep references in 
cache, but then I assume now that the db only mode lacks proper 
constraints in working with database, which should be easy to fix.
Daniel

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