Question

Original Question

mysql-server-6.0.10

I have this problem, I’m using the COMPRESS function to update a field with a BASE64 encoded value. The “updated” base64 string is only slightly different than the value that is currently in the database but it IS different. The only part is different is the last few bytes of the string. The problem is that mysql is seeing these values as the SAME and therefore skipping the update. It returns without error letting my program thing it did what it was told but then you go back and the data is unchagned.

For example, the first one is base64 string that was previously INSERTED to the db, the second one is what I’m trying to overwrite with:

YToxOntpOjA7YToxOntzOjE1OiJ0cmFja2luZ19udW1iZXIiO2k6MjM0MjM0MjM0MzI0MDAwO319
YToxOntpOjA7YToxOntzOjE1OiJ0cmFja2luZ19udW1iZXIiO3M6MTU6IjIzNDIzNDIzNDMyNDExMSI7fX0=

I’m running this query:

UPDATE TABLE SET fieldname=COMPRESS('YToxOntpOjA7YToxOntzOjE1OiJ0cmFja2luZ19udW1iZXIiO3M6MTU6IjIzNDIzNDIzNDMyNDExMSI7fX0=') WHERE id = 'SOMEID';

Mysql comes back with 0 rows affected.

I can reproduce this in an SQL Query window via PHPMyAdmin so I know its not a problem with code.

How can I force this to just update regardless if the strings BEGIN the same way, since it obviously inst checking the entire string? Right now my workaround is to clear the present data with one query, then run another query to update against nothing. This is inefficient though and I’m not happy with it.

First question update

I actually found out this is a result of a PHP bug with JSON_NUMERIC_CHECK!

The value was getting saved in the database properly (couldnt tell because of the compression) but when my script to go back was loading the data out of the database via JSON_ENCODE the values were getting mangled by JSON_NUMERIC_CHECK.

See the bug report I filed:
https://bugs.php.net/bug.php?id=60111

Second question update and solution

So it really turns out I was way ahead of my self on this. I was using JSON_NUMERIC_CHECK incorrectly. I was using it as a blanket solution to ensure all numeric values would be, well, numeric. The flaw in this logic is that JSON_NUMERIC_CHECK’s purpose in life is to attempt to convert all numeric strings to integers, in 32-bit OS environment there is a limit to how many digits an int val can be and thus using the exponential expression as it should!

It comes down to the fact that in my system, there is a possibility of a [tracking number] could actually be an extremely long string of just numbers. JSON_NUMERIC_CHECK was doing exactly what it was suppose to do by converting this to an exponentially expressed int val.

The actual fix to this was to not use JSON_NUMERIC_CHECK and to make sure that my var types were correct where I actually needed int vals before creating the object that is later passed to the front end via JSON.

Phew, a mouthfull, but i figured if anyone else runs into this problem it might be helpful. Chao!

Answer 1

I’m sorry guys, nevermind, the problem is that value i’m supplying is being treated as INT instead of STRING and its over the max size of an INT so its resetting to the MAX INT and therefore being the same string.

Sometimes just thinking through it enough to post a problem on here is enough to help me figure it out 🙂

UPDATE:

I actually found out this is a result of a PHP bug with JSON_NUMERIC_CHECK!

The value was getting saved in the database properly (couldnt tell because of the compression) but when my script to go back was loading the data out of the database via JSON_ENCODE the values were getting mangled by JSON_NUMERIC_CHECK.

UPDATE:

I’m actually just way ahead of my self. using JSON_NUMERIC_CHECK incorrectly. My bad!