Fix decimal marshalling in specific locales

[bjornpost]

In certain locales, the decimal separator is a comma instead of a point, so 12.34 becomes 12,34. This causes an issue with marshalling Decimals; as Pheasant tries to store them as 12,34. MySQL can't handle this and stores 12.00.

This PR fixes the issue and adds a testcase. I used the nl_NL in the testcase, but the fixes works for all locales which use a comma as decimal separator (German, Danish, Swedish, French, Italian, etc.)

[bjornpost]

Oh btw, this does not work for Arabic locales, which use ' as a decimal separator. Adding support for those locales as well would require a more complex solution: http://php.net/manual/en/function.floatval.php#92563 . I don't think that support for that is worth the performance penalty.

[harto]

This seems a bit odd. Surely the Mysqli driver can do the right thing with PHP's float type regardless of locale. Is the issue that your float values are being prematurely converted to strings?

[jorisleker]

Floats are casted to strings when creating sql statements in PHP (that's what Pheasant does, isn't it), ergo before they reach the mysqli driver.

PHP's behavior with LC_ALL or LC_NUMERIC set to a locale with ',' as decimal sep is asymmetric. ((float) '2.13' results in 2,13, but (string) 2,13 results in 2)

Question remains whether Pheasant should support other locales in LC_NUMERIC or just discourage that. I think that should clearly be stated somewhere in the docs though.

[bjornpost]

Thoughts @lox?

[lox]

Interesting problem. This is ultimately solved by moving away from Pheasant's userspace param binding and deferring entirely to the underlying mysqli implementation. I'm going to address this in 2.0.

In the meantime, I'd suggest setting setlocale(LC_NUMERIC, 'en-US') in your code that is using Pheasant.