[sr-dev] mysql_db and UPDATE

[Jason Penton]

ok agreed, will add it in.


On Wed, Aug 13, 2014 at 11:58 AM, Daniel-Constantin Mierla <
miconda at 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 at speakup.nl> wrote:
>
>> On Friday 08 August 2014, Jason Penton wrote:
>> > 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 at lists.sip-router.org
>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>>
>
>
>
> _______________________________________________
> sr-dev mailing listsr-dev at 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 at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20140813/3ea72a36/attachment.html>