2014-06-19 10 views
7

Ecco la mia schema.rbRails 4 Migrazione: Mysql2 :: Errore: dati troppo lungo per la colonna 'xxxx'

create_table "users", force: true do |t| 
    t.string "name",  limit: 6 
    t.string "email" 
    t.datetime "created_at" 
    t.datetime "updated_at" 
    end 

ho impostato il limite fo stringa per la colonna "nome".

Poi, in console:

user = User.new(name:"1234567890",email:"[email protected]") 
user.save! 

ha sollevato l'errore:

ActiveRecord::StatementInvalid: Mysql2::Error: Data too long for column 'name' at row 1: INSERT INTO `users` (`created_at`, `email`, `name`, `updated_at`) VALUES ('2014-06-19 15:08:15', '[email protected]', '1234567890', '2014-06-19 15:08:15') 

Ma, quando sono passato a rotaie 3.

l'ho trovato troncato la stringa "" automaticamente e inserito "" in base di dati senza errori.

È stato rimosso qualcosa nelle guide ?

Devo aggiungere alcune funzioni troncate nel modello da solo? Grazie!

+1

Per l'ultima domanda, può dipendere dal vostro caso d'uso per la creazione 'user'. Forse potrebbe essere meglio aggiungere un validatore per verificare la lunghezza su ': name' e mostrare un errore all'utente se finisce troppo a lungo? –

+0

La convalida è probabilmente la strada da percorrere, perché un utente dovrebbe sapere che il suo nome non può essere più lungo di 6 caratteri. Altrimenti potrebbero essere sorpresi quando entrano in "Jonathan", ma quando guardano il loro profilo il loro nome è elencato come "Jonath". –

+0

Grazie, ho capito che il modo migliore è aggiungere un po 'di validazione. Ma voglio solo capire cosa è cambiato in Rails 4, e alcuni modelli sono invisibili agli utenti, quindi in questo caso la convalida non può aiutarmi. – tzzzoz

risposta

16

Quello che stai vedendo è una differenza in MySQL, non Rails. Di default, MySQL troncherà i dati troppo lunghi piuttosto che generare un errore. Se si imposta MySQL sulla modalità strict, genererà errori invece di troncare silenziosamente i dati.

Con la versione 4, Rails turns on strict mode per impostazione predefinita. Ecco perché stai riscontrando un comportamento diverso con Rails 3. Questo è il comportamento che probabilmente desideri. Il troncamento silenzioso dei dati è quasi sempre negativo e può comportare un comportamento molto confuso per gli utenti.

Se davvero desidera troncare i dati, è possibile turn off strict mode o utilizzare un filtro di prima:

before_save :truncate_username 
def truncate_username 
    self.username = username.slice(0, 6) 
end 
+0

Grazie, è utile! Salvavita – tzzzoz

7

Mi sono imbattuto in this article in coincidenza, scritto solo pochi giorni fa.

Il punto principale di interesse è questo:

...I recently upgraded from rails 3.2 to rails 4.0. They implemented a major change with ActiveRecords that I can find no mention of any where except in the source and change log.

  • mysql and mysql2 connections will set SQL_MODE=STRICT_ALL_TABLES by default to avoid silent data loss. This can be disabled by specifying strict: false in your database.yml .

Ciò sembrerebbe spiegare perché hai smesso di ricevere l'errore quando si è ritornata ad Rails 3. Si può vedere questo nelle opzioni del MySQL connection adapter module, e sembra che fosse added way back in May 2012 per la versione 4.1.2 candidata (se sto leggendo i tag correttamente).

Questa persona ha risolto il problema con il codice ... [fixing] per ottenere le lunghezze dei campi appropriate o per troncare manualmente i dati ....

Nel tuo caso, potresti riuscire a risolvere il tuo problema in Rails 4 semplicemente aggiungendo strict: false nel tuo database.yml. Se si desidera personalizzare il modo in cui i dati vengono troncati, concordo con il suggerimento di JKen13579 sul callback before_save. In caso contrario, da quello che posso vedere, sembra troncare i caratteri più a destra, quindi se è sufficiente, è possibile che si possa ottenere il comportamento di troncamento predefinito.

+1

Grazie, è chiaro per me! – tzzzoz

+1

Questa risposta non fa solo riferimento a un articolo che spiega in realtà qual è il vero problema, dopo averlo letto si può anche capire perché solo l'affettare i dati stessi sulla migrazione sia altrettanto brutto. Ottima risposta @ paul-richter – josethernandezc

Problemi correlati