2013-03-26 18 views
5

Ho appena notato che la propulsione converte i valori numerici in stringhe nei metodi setter generati. Il mio problema con questo è, dal momento che sto usando locale tedesco, i valori float sono inseriti con una virgola invece di un punto. Ad esempio: "3.5" restituisce una stringa "3,5". Sto usando PostgreSQL, che ovviamente si aspetta 3.5.Perché propel convertire la proprietà float in stringa?

Info versione: Nel caso sia rilevante, sto usando: PHP 5.3.9, Propel 1.6 con Symfony 2.2.

Dettagli:

La definizione della tabella si presenta così:

<table name="account_entry"> 
    ... 
    <column name="amount" type="decimal" size="12" scale="2" required="true" /> 
    ... 
</table> 

Il setAmount generato() il metodo seguente aspetto:

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() 

Salvare i risultati degli oggetti in un PostgreSQL errore:

Invalid text representation: 7 ERROR: invalid input syntax for type numeric: "3,5" 

Mi ci è voluto un po 'per trovare il luogo in cui avviene questa conversione. Come puoi vedere il valore float viene castato in string in setAmount(). Fino ad ora non ho mai notato che il casting di un valore float per risultati stringa in una stringa contenente un separatore decimale specifico locale.

Mi chiedo perché propel converte un valore float in una stringa in primo luogo? C'è qualche soluzione per questo?

L'unica soluzione che mi è venuta è davvero brutto e fastidioso:

setlocale(LC_ALL, 'en_US'); 
$ae->setAmount(3.5); 
setlocale(LC_ALL, 'de_DE'); 
+0

Sembra che sia [il comportamento * predefinito * (https://github.com/propelorm/Propel/blob/master/generator/lib/builder/om/PHP5ObjectBuilder.php#L1844-1873) da gestire colonna. Ma in base al modo in cui viene generato l'SQL (per inserire, ad esempio), [sembra] (https://github.com/propelorm/Propel/blob/master/generator/lib/builder/sql/DataSQLBuilder.php#L172 -180) che dovrebbe essere convertito * di nuovo * in modo che corrisponda al tipo di colonna nativa. Puoi controllare [problema su Github] (https://github.com/propelorm/Propel/issues) e/o inviare uno – j0k

+0

Grazie per la tua ricerca. Ho postato la domanda sulla mailing list propel. Voglio evitare di creare segnalazioni di bug, se potrebbe non essere un bug. – Leif

risposta

5

Il problema è che Propel converte il campo di PHP che si riferisce a quella colonna in un tipo di PHP nativo nel setter (come @ J0K cita), ma se guardi un po 'più a fondo vedi il problema. Nella classe helper PropelTypes.php, nella riga 76 si può vedere che il tipo nativo di PHP per "decimale" è elencato come "stringa".

Confrontare questo con il tipo nativo "float" che è elencato come "doppio". Non sono sicuro che sia intenzionale o meno, ma in ogni caso il problema potrebbe essere risolto semplicemente passando la colonna su type="float" o type="double".

Propel deve convertirlo in qualsiasi tipo richiesto dal DBMS.

+0

Grazie! Cambiare il tipo da decimale a doppio effettivamente risolve il mio problema. Lo considero comunque una soluzione, perché PostgreSQL usa double come type now e non decimal (x, y). Ma questo va bene per il mio caso. – Leif

+0

Felice che funzionasse. Onestamente non sono sicuro del motivo per cui la gente di base di Propel avrebbe predefinito il tipo nativo a "stringa", ma forse ha senso per alcuni DBMS. – jakerella

+3

È perché il campo DECIMAL nei database è preciso, mentre la gestione nativa in virgola mobile sulla CPU non lo è. Così Propel è sicuro ripagando il valore esatto in una stringa e lasciandoti preoccupare dell'aritmetica e della memorizzazione. Vedi f.e. [Link] (http://msdn.microsoft.com/en-us/library/c151dt3s%28v=vs.80%29.aspx) – Noora

Problemi correlati