[Rails] validates_uniqueness_of ne renvoie pas de message mais écrase l'ancienne donnée

[Maz]

Bonsoir, il ne m'en a pas fallu beaucoup de temps pour être confronté à un nouveau problème. J'aimerais limité le champs d'un de mes modèle pour qu'il soit unique, j'ai cherché et suis tombé sur "validates_uniqueness_of, j'ai donc tout fait comme il le fallait, ma migration contient la ligne:

add_index :cities, :name, :unique => true

Et mon modèle:

class City < ActiveRecord::Base

  belongs_to :user

  has_many :ants

  

  validates_uniqueness_of :name

Et ça fonctionnes... il n'y a qu'un seul champs de chaque "name", mais c'est parce qu'à chaque fois, si le name est déjà pris, il est écrasé!

[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 :

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.

[Viciousity]

Je suis d'accord avec Sephi, j'ai beaucoup de validations d'unicité et jamais ton problème :S

Par contre je serais de toi, j'utiliserais les validateurs comprimés du genre :

validates :name,

  presence:   true

  uniqueness: true

[popayan]

Pareil, jamais eu ce comportement!

par contre, comme on m'a dit d'utiliser les "validates_uniqueness_of", "validates_presence_of" etc..., j'aimerais avoir l'avis de Sephi (même si je pense que les 2 méthodes sont aussi bonnes)

[Sephi-Chan]

Tu peux utiliser indifféremment la nouvelle forme de validation (validates) ou l'ancienne (validates_*). L'ancienne n'est pas dépreciée, c'est juste une question de préférence.

Si tu dois valider la présence de plusieurs attributs et que parmi ces attributs certains n'ont pas d'autres validateurs, c'est plus court d'opter pour l'ancienne forme.

Tu peux même les mélanger sans problème, par exemple :

class Participation < ActiveRecord::Base

  COLORS = %w( blue green orange purple yellow )

  

  belongs_to :game

  belongs_to :player

  

  validates_presences_of :game, :player, :color

  validates :color, in: Participation::COLORS

end

Ici on aurait pu mettre une clé presence à true, mais c'est plus simple de profiter du validates_presences_of.

[Maz]

Ok. Je go suicide sur ce coup là.

J'ai fait les tests: ça fonctionnes comme Sephi-chan
J'ai regarder le serveur rails pendant que j'exécutais mes pages et j'ai remarquer qu'il y avait un DELETE qui se faisait o_o:
j'avais oublié un last_created_city.destroy dont je m'étais servis pour débugger...

Au moins on auras eu le droit à quelques éclaircissements sur les fonctions de validations...

Je tâcherais à ce que celà ne se produises plus...

[Sephi-Chan]

L'abus du forum est dangereux pour la santé. Créer des sujets avec modérations et après avoir fait quelques tests et recherches.

[Maz]

Bah en fait je conaissais pas la console rails...

[Sephi-Chan]

Ça n'aura pas été inutile alors !