[sr-dev] mysql_db and UPDATE

[Daniel-Constantin Mierla]

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 
> <mailto: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 <mailto:sr-dev at lists.sip-router.org>
>     http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>
>
>
>
> _______________________________________________
> sr-dev mailing list
> sr-dev at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

-- 
Daniel-Constantin Mierla
http://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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20140813/71fcebd6/attachment.html>