29-09-2011, 09:52 PM
(Modification du message : 29-09-2011, 10:07 PM par Sephi-Chan.)
La contrainte d'unicité au niveau de la table n'est pas indispensable, bien qu'elle soit une garantie (Rails ne pouvant t'offrir cette garantie absolue).
En revanche, le comportement que tu décris n'est pas cohérent. De plus, la batterie de tests de Rails est conséquente et un tel comportement ne serait jamais passé.
Exemple dans la console Rails :
Tu dois faire une erreur ailleurs. Effectue le même test que moi dans une console Rails et montre-nous le résultat.
En revanche, le comportement que tu décris n'est pas cohérent. De plus, la batterie de tests de Rails est conséquente et un tel comportement ne serait jamais passé.
Exemple dans la console Rails :
ruby-1.9.2 :001 > City.create(name: "Foo")
(0.1ms) SELECT 1 FROM "cities" WHERE "cities"."name" = 'Foo' LIMIT 1
SQL (69.8ms) INSERT INTO "cities" ("created_at", "name", "updated_at") VALUES (?, ?, ?) [["created_at", ...], ["name", "Foo"], ["updated_at", ...]]
=> #<City id: 1, name: "Foo", created_at: "2011-09-29 19:51:29", updated_at: "2011-09-29 19:51:29">
ruby-1.9.2 :002 > City.create(name: "Foo")
(0.1ms) SELECT 1 FROM "cities" WHERE "cities"."name" = 'Foo' LIMIT 1
=> #<City id: nil, name: "Foo", created_at: nil, updated_at: nil>
ruby-1.9.2 :003 > _.errors
=> #<ActiveModel::Errors:... @base=#<City id: nil, name: "Foo", created_at: nil, updated_at: nil>, @messages={:name=>["has already been taken"]}>
Tu dois faire une erreur ailleurs. Effectue le même test que moi dans une console Rails et montre-nous le résultat.