I am not sure what happened, but I've just updated to 6.5.5 and pushed my updates to remote. Suddenly all numeric action on my website now returns NAN. Apparently mysql returns Decimal and Numeric values with 6566.99m (Where did this M come from). Any fix in sight?
What database are you using and what server model?
Node.js
MySQL
We had a similar issues with storing numeric data in MySQL as decimal (you will need to format decimal values to number). Patrick explained the fundamentals to me here:
We have just had another issue with today's update whereby our leaflet maps were not rendering as we were storing geo-coordinates as decimal 10,4. We changed how they are stored and everything is now back to normal.
Just thought it may be related?
1 Like
Hi CHeese,
Yes, I saw this particular update from you and @patrick and I've been using the same logic ever since.
EVen with this, I get this:
Yes decimal fields are now fully supported and send to the client side app connect in a special notation ending with ‘m’ to be recognized and threaten as decimals client side as well - this is the new upcoming JavaScript standard as well.
App Connect should pick up the new decimals and show and format them well.
Do note that just as with the new bigint (those end with ‘n’) all involved numbers in an expression should be of the same type!
So you can’t have:
22.44m + 1
But should be:
22.44m + 1m
That is why we also have formatters to convert to decimals and bigint now.
1 Like
Not only decimals but even integer cell types return NaN. All of my already added bindings seem to work. But any new ones don't show up at all unless I format to number and then it shows NaN.
I don't know why this change was made! There was nothing wrong with it the way it was! Numbers are completely busted now.
I sort of have it working. Trying to pin down a pattern of when it works and when it doesn't. I don't get the 'm' on the end on a straight binding at all.
Lol. If it aint broke, why fix it? right? I was just thinking the same right now. 
2 Likes
Such a change shouldn't have been done like this, it could break functionality outside Wappler (e.g.: an external program calls a Server Action)
4 Likes
Totally agree. I have a lot of external api querys and We have been working for several hours tonight (in Europe it is 8 a.m.) adapting and changing queries in SQL directly so as not to affect the front-end and external APIs. In this case, we are removing the decimals even temporarily until we have a better solution.
At the moment we use CAST('123' AS UNSIGNED)
Agreed,
We will be reverting the automatic conversion and add the decimal handling under an option.
Only there are so many places to add such an option... should it be per database connection (as it is actually for mysql2 driver for node), or Server Connect global options, or per database query?
Perhaps this should have been set as an experiments feature until users had a chance to test sites before applying
It was not intended for release and was added by accident. The BigInt and Decimal support is still Work in Progress and not finished. We will release an inline update today to undo the change and revert the old behavior.
An inline update has been released, it reverts the old behavior back, so no m will be added to the values.
2 Likes
Per database query sounds ok to me
Per database connection please.
1 Like
Per database connection would allow more effective for switching between settings for testing.
Then user could switch database connection, test, go back, tweak ... repeat
1 Like