[sr-dev] mysql_db and UPDATE

[Jason Penton]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20140808/f552aa6b/attachment.html>