2014-06-19 11 views
7

Hier ist meine schema.rbRails 4 Migration: mysql2 :: Fehler: Daten zu lang für Spalte '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 

ich die Grenze fo Zeichenfolge für die Spalte "Name" gesetzt.

Dann in der Konsole:

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

Es erhöht den Fehler:

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

Aber, wenn ich auf Schienen 3 geschaltet.

Ich fand es die Schnur abgeschnitten ohne Fehler "" automatisch und eingefügt "" in der Datenbank.

Wurde irgendetwas in rails 4 entfernt?

Sollte ich einige Funktionen im Modell selbst hinzufügen? Vielen Dank!

+1

Für die letzte Frage kann es auf Ihren Anwendungsfall ab, für 'User' Schöpfung. Vielleicht ist es besser, einen Validator hinzuzufügen, um die Länge von ': name' zu ​​prüfen und dem Benutzer einen Fehler anzuzeigen, wenn er zu lange endet? –

+0

Validierung ist wahrscheinlich der Weg zu gehen, weil ein Benutzer wissen sollte, dass ihr Name nicht länger als 6 Zeichen sein kann. Andernfalls könnten sie überrascht sein, wenn sie "Jonathan" eingeben, aber wenn sie ihr Profil ansehen, wird ihr Name als "Jonath" aufgeführt. –

+0

Danke, ich verstehe, der bessere Weg ist es, eine Validierung hinzuzufügen. Aber ich möchte nur herausfinden, was in Rails 4 geändert wurde, und ich habe einige Modelle, die für Benutzer unsichtbar sind. In diesem Fall kann mir die Validierung nicht helfen. – tzzzoz

Antwort

16

Was Sie sehen, ist ein Unterschied in MySQL, nicht in Rails. Standardmäßig schneidet MySQL Daten ab, die zu lang sind, anstatt einen Fehler auszulösen. Wenn Sie MySQL auf den Modus strict setzen, werden Fehler ausgelöst, anstatt Daten stillschweigend zu kürzen.

Mit Version 4, Rails turns on strict mode standardmäßig. Aus diesem Grund sehen Sie ein anderes Verhalten bei Rails 3. ist das Verhalten, das Sie wahrscheinlich möchten. Daten still zu schneiden ist fast immer schlecht und kann zu sehr verwirrendem Verhalten für Benutzer führen.

Wenn Sie wirklich die Daten abschneiden möchten, können Sie turn off strict mode oder verwenden Sie einen vor Filter:

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

Danke, es ist hilfreich! Lebensretter – tzzzoz

7

Ich stolperte über this article zufällig vor nur ein paar Tagen geschrieben. dies ist

Der wichtigste Punkt von Interesse:

...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 .

Dies würde zu erklären, warum scheinen Sie empfangen den Fehler gestoppt, wenn Sie zurück in Rails 3 zurück Sie dies in den Optionen des MySQL connection adapter module sehen können, und es sieht so aus, als wäre es added way back in May 2012 für den Release-Kandidaten 4.1.2 (wenn ich die Tags richtig lese).

Diese Person löste ihr Problem durch ... [Fixieren] Code entweder die richtigen Feldlängen zu haben, oder die Daten manuell zu kürzen ....

In Ihrem Fall könnten Sie Ihr Problem in Rails 4 lösen, indem Sie einfach strict: false in Ihrem database.yml hinzufügen. Wenn Sie anpassen möchten, wie die Daten abgeschnitten werden, stimme ich dem Vorschlag von JKen13579 über den Rückruf before_save zu. Ansonsten, von dem, was ich sehen kann, scheint es die rechtesten Zeichen abzuschneiden, wenn das ausreicht, können Sie wahrscheinlich mit dem Standardkürzungsverhalten davonkommen.

+1

Danke, es ist klar für mich! – tzzzoz

+1

Diese Antwort zeigt nicht nur auf einen Artikel, der tatsächlich erklärt, was das eigentliche Problem ist, nach dem Lesen können Sie auch sehen, warum nur Daten auf der Migration selbst schneiden genauso schlecht ist. Große Antwort @ Paul-Richter – josethernandezc

Verwandte Themen