13 Aug
2014
13 Aug
'14
5:34 p.m.
ok agreed, will add it in.
On Wed, Aug 13, 2014 at 11:58 AM, Daniel-Constantin Mierla <
miconda(a)gmail.com> wrote:
Hello,
maybe this can be introduced as a module parameter option for db_mysql. It
will allow fixing quickly via config if similar situation arises. If it
proves to become a common case, then it can turned on by default.
Cheers,
Daniel
On 08/08/14 16:12, Jason Penton wrote:
Hi Alex,
I didn't check the table schemas for usrloc but I'm sure there may be
other cases where the affected_rows function has been 'misunderstood'. In
the code I picked this bug up (ims_pcscf_usrloc), I did exactly that,
change the schema. Just wanted to discuss in case it was decided to change
the connect flags to mitigate any future probs.
Also, if you merely change the the schema, some code would think the
update had "failed" and do some other adverse failure code so not sure that
would be an ideal final fix...
Cheers
Jason
On Fri, Aug 8, 2014 at 4:06 PM, Alex Hermann <alex(a)speakup.nl> wrote:
On Friday 08 August 2014, Jason Penton wrote:
_______________________________________________
sr-dev mailing
listsr-dev@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
--
Daniel-Constantin Mierlahttp://twitter.com/#!/miconda -
http://www.linkedin.com/in/miconda
Next Kamailio Advanced Trainings 2014 - http://www.asipto.com
Sep 22-25, Berlin, Germany ::: Oct 15-17, San Francisco, USA
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
I have noticed that in some instances if you
update a row in mysql via
the
mysql_db module and the actual row data does not
change - affected_rows
will return 0. This is the default behaviour for the mysql API as per -
http://dev.mysql.com/doc/refman/5.0/en/mysql-real-connect.html
There is a flag (CLIENT_FOUND_ROWS) that can be used in the
mysql_real_connect function that will cause affected_rows to return the
number of rows that were "matched" - ie in the WHERE clause, as opposed
to
whether or not any data was changed.
If we don't it could be a problem for modules like usrloc where an
update
is done and if no row are "affected"
and new row is added which would
cause
a duplicate.
If that happens, the table definition is wrong. It should have (a) unique
key(s) to prevent double records. We'd better fix that.
--
Greetings,
Alex Hermann
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev