Implicit float to string conversion leads to database incorrect SQL update

We're using Projeqtor version 4.5.4 and french language browsers.

In the last week or so we began to notice erroneous behaviour when submitting data - real work input. At that time we were using version 4.5.3 but updating to version 4.5.4 didn't solve the issue. The problem arises when decimal values are input - eg 0,6 would result in 0 being saved in the database.

First I changed MySQL configuration so as to prevent incorrect data being saved in the database (STRICT_ALL_TABLES) because I suspected this was related to a comma/point issue as we were using the french language and the issue only happened with decimal numbers. From there on, we got the attached eror message from Projeqtor when things were going bad. At least the database was not corrupted and we could retry the data update until we succeeded.



By retrying we would finally be able to save the data ! All this was reminding me of an issue we got last year and for which I submitted a post: Work allocation in half-days

I don't have a clue why we seem to get the same problem again because I didn't change the Apache configuration nor TRAC configuration and there was no software update for both in the last weeks...

Anyway I traced the problem to the following line of code (/model/persistence/SqlElement.php: line 793) :

$col_new_value is of type float when input into the trim function then becomes a string when it receives value from the output of the said trim function. As that function expects a string as input parameter, there is an implicit float to string conversion which depends on the locale defined at the time the trim function is called. When the locale is a french one, the float is converted to '0,6' whereas when the locale is an english one the float is converted to '0.6'.

When a comma appears as a result of the implicit float to string conversion the SQL query which is built from it to update the mySQL database either saves the value 0 (the integer part of 0,6) when mySQL mode is not strict or fails with an error otherwise.

To make a fast patch I added the following line of code just after the previous one:

This is just a fast patch and I guess you will bring a better global solution to this issue. At least it seems to me abnormal to apply the trim function to a float !

I didn't find setlocale() calls in the source code so I wonder how the PHP code gets its locale. I tried to modify the locale definition at the Apache level but that didn't seem to have any impact on the locale used for the float to string conversion. As localization is handled at the Dojo level if I'm correct, and input values are always transmitted to the server as strings with decimal points - not commas, wouldn't it be safer to explicitly set the locale in the PHP code ?

Regards

Hi babynus,

I'm not in the position of answering your questions regarding reproducing the issue on Real Work allocation and activity because the issue has gone for me after restarting my virtual machine. I guess some updates got active as a result of it. I didn't make a clear link between those updates and Projeqtor, unfortunately.This was 3 weeks ago and since then we didn't notice the issue anymore.

Thank you babynus for trying to reproduce the issue and for patching the code for the implicit float to string conversion. I will come back to you if the issue occurs again.

Regards