I just noticed, that propel converts numeric values to strings in generated setter methods. My problem with that is, since I am using german locale, float values are insert with a comma instead of a dot. For example: "3.5" results in a string "3,5". I am using PostgreSQL, which obviously expects 3.5.
Version info: In case it is relevant, I am using: PHP 5.3.9, Propel 1.6 with Symfony 2.2.
Details:
The table definition looks like this:
<table name="account_entry">
...
<column name="amount" type="decimal" size="12" scale="2" required="true" />
...
</table>
The generated setAmount() method looks like this:
public function setAmount($v)
{
if ($v !== null && is_numeric($v)) {
$v = (string) $v;
}
if ($this->amount !== $v) {
$this->amount = $v;
$this->modifiedColumns[] = AccountEntryPeer::AMOUNT;
}
return $this;
} // setAmount()
Saving the object results in a PostgreSQL error:
Invalid text representation: 7 ERROR: invalid input syntax for type numeric: "3,5"
It took me a while to find the place where this conversion happens. As you can see the float value is being casted to string in setAmount(). Up to now I have never noticed that casting a float value to string results in a string containing a locale specific decimal separator.
I wonder why propel converts a float value into a string in the first place? Is there some workaround for this?
The only workaround I came up with is really ugly and annoying:
setlocale(LC_ALL, 'en_US');
$ae->setAmount(3.5);
setlocale(LC_ALL, 'de_DE');
The problem is that Propel converts the PHP field that relates to that column into a native PHP type in the setter (as @j0k mentions), but if you look a little deeper you see the issue. In the PropelTypes.php helper class, on line 76 you can see that the native PHP type for "decimal" is listed as "string".
Compare this to the "float" native type which is listed as "double". I'm not sure if this is intentional or not, but in any case, your issue may be solved by simply switching the column to type="float"
or type="double"
.
Propel should convert that into whatever type your DBMS requires.