Le Jeu 31 août 2006 16:57, Samuel DECHOMETS a écrit : > Le problème vient toujours du fait que l'utilisation de Rails dans ma > société est récente et que le design des bases n'est pas > "Rails-optimized".
Ce dont j'ai parlé est finalement assez décorrélé de Rails. L'idée d'utiliser deux colonnes (une pour la date, une pour savoir si c'est limité, et le null pour savoir si c'est renseigné) est plus lié à ce que tu veux stocker (deux informations) qu'au code qu'il y a derrière. Tu as deux informations, tu devrais avoir (au moins) deux champs. > De manière plus générale, je n'ai pas encore le "duck typing" inné, car > si mes souvenirs sont bons, le fait d'avoir une méthode has_time_limit > vient de là ? Quelqu'un a-t-il déjà fait ou vu un mémo associant les > principaux type de données aux classes Ruby correspondantes (ex: Tinyint > (1) => trueClass ou falseClass, DATE => date Class...). C'est un coup de magie d'ActiveRecord. Si tu as un tinyint(1) qui s'appelle "has_time_limit", ActiveRecord te permet d'accéder à cet entier (0 à 9) via la méthode "has_time_limit" mais permet aussi d'y accéder avec la méthode "has_time_limit?", avec un point d'interrogation. Dans ce dernier cas, c'est lui qui fait automatiquement la transposition entre 0/1 et true/false. L'idée d'AR c'est de penser qu'un champ booléen devrait logiquement avoir une méthode en "?", qu'il s'agit d'une question. Et pour le même prix ça leur permet de gérer sans trop se casser la tête la dualité entier/booléen. Sinon pour la liste, le booléen est le seul type géré "différement" que je connaisse. Pour le reste une date/heure se retrouve dans un objet Time, un nombre dans une classe appropriée de nombre en ruby, un texte en String, un NULL en Nil. De mémoire il n'y a rien d'autre. -- Eric Daspet _______________________________________________ Railsfrance mailing list [email protected] http://lists.rubyonrails.fr/mailman/listinfo/railsfrance
