Active Record : les migrations

ActiveRecord est le composant qui permet la manipulation des données dans les applications Ruby on Rails. ActiveRecord est aussi et avant tout un design pattern pour lier les données d'une base de données à des modèles de programmation. Voici la définition très juste de ce design pattern trouvée sur Wikipedia : « En génie logiciel, le patron de conception (design pattern) active record (enregistrement actif en anglais) est une approche pour lire les données d'une base de données. Les attributs d'une table ou d'une vue sont encapsulés dans une classe. Ainsi, l'objet instance de la classe est lié à un tuple de la base. Après l'instanciation d'un objet, un nouveau tuple est ajouté à la base au moment de l'enregistrement. Chaque objet récupère ses données depuis la base; quand un objet est mis à jour, le tuple auquel il est lié l'est aussi. La classe implémente des accesseurs pour chaque attribut. » Voici un exemple concret : si nous avons une table « contacts » dans la base de données de notre application Rails, alors nous avons forcément une classe Contact qui peut être manipulée via ActiveRecord. Voici un exemple de code :

  c = Contact.new(:first_name => "Dubois", :last_name => "Vincent")
  c.save   # création du tuple

Avant de rentrer dans le détail des migrations Active Record, voyons un exemple de migration que nous avons créé dans le tutoriel précédent :

  class CreateContacts < ActiveRecord::Migration
    def self.up
      create_table :contacts do |t|
        t.string :name
        t.string :email

        t.timestamps
      end
    end

    def self.down
      drop_table :contacts
    end
  end

Cette migration ajoute une table « contacts », possédant deux colonnes « name » et « email » de type texte. La méthode « timestamps » quant à elle, ajoute des colonnes d'informations sur les dates de mises à jour des enregistrements. Nous détaillerons tout cela un peu plus tard.

II-A. Les migrations sont des classes▲

III-A. Créer un modèle▲

ruby script/generate model Contact name:string email:string

III-B. Créer une migration seule▲

ruby script/generate migration AddFirstNameToContacts

class AddFirstNameToContacts < ActiveRecord::Migration
    def self.up
    end

    def self.down
    end
  end

def self.up
    add_column :contacts, :first_name, :string
    rename_column :contacts, :name, :last_name
  end

def self.down
    remove_column :contacts, :first_name
    rename_column :contacts, :last_name, :name
  end

ruby script/generate migration AddFirstNameToContacts first_name:string

IV-A. Créer une table▲

create_table :contacts, :force => true do |t|
    t.string :name
  end

t.column :name, :string, :null => false

t.string :name, :null => false

t.column :name, 'autre_type', :null => false

IV-B. Modifier une table▲

  change_table :contacts do |t|
    t.remove :email, :country
    t.string :address
    t.index :first_name
    t.rename :first_name, :firstname
  end

  remove_column :contacts, :email
  remove_column :contacts, :country
  add_column :contacts, :address, :string
  add_index :contacts, :first_name
  rename_column :contacts, :first_name, :firstname

IV-C. Helpers spéciaux▲

t.references :category

Rails nous fournit un certain nombre de tâches Rake qui permettent de manipuler les migrations. Celle que nous utiliserons le plus souvent est la commande « rake db:migrate ». Elle peut être agrémentée du numéro de version de migration à atteindre. Dans ce cas, les migrations suivantes ne sont pas effectuées. Par exemple :

rake db:migrate VERSION=20090420203025

Dans l'exemple ci-dessus, la version correspond au préfixe du fichier de migration. Nous pouvons également exécuter l'opération inverse, c'est-à-dire décrémenter le niveau des migrations. Pour cela, Rails met à notre disposition la méthode « rake db:rollback ». Seule, la commande permet de descendre d'un niveau de migration à chaque exécution. On peut, comme pour la commande « migrate », préciser « VERSION=… ». Dans ce cas, on descend le niveau de migration jusqu'à la version donnée en paramètre. Le mieux pour l'opération rollback, est quand même de préciser le paramètre « STEP » pour descendre plusieurs niveaux de migrations à la fois. Par exemple :

rake db:rollback STEP=3

Voici le diagramme de classes de notre application de gestion des contacts : nous souhaitons qu'un utilisateur puisse gérer ses propres contacts. Chaque contact pourra avoir plusieurs numéros de téléphone, messageries instantanées, sites web, adresses postales, et adresses email.

Avant de créer les migrations qui vont nous permettre de modéliser la base de données, nous devons supprimer les migrations que nous avons ajoutées précédemment :

rake db:rollback STEP=2
  rm db/migrate/*

Maintenant que la base de données est vierge, nous pouvons créer nos entités. Il est néanmoins temps de faire un point sur le modèle. Certaines choses peuvent être mutualisées. C'est le cas par exemple de la gestion des utilisateurs. Plutôt que de créer de zéro une gestion des utilisateurs, nous allons appliquer le principe « DRY » et utiliser le plugin « restful_authentication ». Ce plugin va nous permettre de gérer tous les enregistrements et connexions des utilisateurs à l'application. Commençons par l'installer :

ruby script/plugin install git://github.com/technoweenie/restful-authentication

Le plugin est maintenant installé dans notre répertoire vendor/plugins. Pour créer l'entité « User » et la structure des tables utilisateurs en base de données, lançons la commande :

ruby script/generate authenticated user sessions --include-activation

Cette commande crée beaucoup de choses, notamment l'entité « User » (fichier app/models/user.rb) et le fichier de migration correspondant db/migrate/[VERSION]_create_users.rb. Sachez, pour finir, que le plugin génère des contrôleurs et vues qui permettent de gérer les utilisateurs et les sessions d'authentification. Il rajoute au fichier routes.rb des routes qui facilitent l'utilisation de ces contrôleurs (exemples : /signup, /register, /login, /logout). Nous verrons en détail ce plugin dans un autre chapitre quand nous en saurons plus sur les contrôleurs. Le but ici était d'initialiser l'entité « User ». Concentrons-nous maintenant sur la création des autres entités. À cette fin, lançons les commandes suivantes :

  ruby script/generate model Phone phone_type:integer phone_number:string is_main:boolean

  ruby script/generate model InstantMessaging protocol:integer address:string is_main:boolean

  ruby script/generate model Website url:string is_main:boolean

  ruby script/generate model Address address_type:integer address_street:string address_postcode:string
  address_city:string address_region:string address_country:string is_main:boolean

  ruby script/generate model Email email_type:integer email_address:string is_main:boolean

  ruby script/generate model Contact first_name:string last_name:string nickname:string birthdate:date
  photo:string company_name:string company_department:string company_position:string notes:text

Nous devons ensuite rajouter à la main les liens entre les différentes entités. Pour cela, nous allons utiliser la méthode «references » que nous avons étudiée dans le paragraphe 3.3. Ajoutons la ligne :

t.references :contact

dans les méthodes create_table des fichiers de migrations correspondant aux entités « Phone », « InstantMessaging », « Website », « Address » et « Email » pour faire le lien entre ces entités et l'entité « Contact ». Le lien entre les deux entités « Phone » et « Contact » se lit : un contact possède de zéro à plusieurs numéros de téléphone. Pour finir, il reste à faire le lien entre les utilisateurs et les contacts. Dans le fichier de migration de l'entité « Contact », ajoutons :

t.references :user

Une dernière chose maintenant. Si vous êtes observateur, vous vous êtes probablement aperçu qu'il manque un attribut à l'ensemble du modèle. Il y a un attribut « tag » appartenant à l'entité « Contact ». Cet attribut veut seulement dire que l'on doit pouvoir « tagger » un contact avec un à plusieurs mots. On pourra générer par exemple avec ce genre de données un « nuage de tags » des contacts. Cette fonctionnalité existe déjà dans Rails par l'intermédiaire de plugins. ActsAsTaggableOnSteroids en est un. Nous l'étudierons plus en détail dans un autre chapitre. Nous allons l'installer et l'utiliser pour le raccorder à notre modèle :

ruby script/plugin install http://svn.viney.net.nz/things/rails/plugins/acts_as_taggable_on_steroids

Ensuite nous devons créer la migration correspondante à l'aide de la commande :

ruby script/generate acts_as_taggable_migration

La dernière chose à faire est de rajouter la fonctionnalité de « tagging » aux contacts. Nous devons ouvrir le fichier app/models/contact.rb et le compléter comme suit :

class Contact < ActiveRecord::Base
    acts_as_taggable
  end

Voilà, tous nos modèles sont décrits, toutes les migrations correspondantes sont écrites et l'apport de certains plugins a permis de nous prémâcher beaucoup de travail. N'oublions pas de mettre à jour la base de données avant de passer à la suite :

rake db:migrate

ActiveRecord est LE composant de Rails qu'on se doit de connaître sur le bout des doigts. Une bonne conception de la base de données passera forcément par une écriture correcte des migrations. Les migrations sont un outil puissant, car elles permettent de gagner un temps fou lors de l'initialisation d'un projet Rails. On ne doit pas les négliger. Dans la prochaine partie, nous aborderons le développement par les tests dans Ruby on Rails. Nous verrons quel est leur rôle et comment en tirer un maximum de bénéfice. Vous pouvez retrouver le source de ce tutoriel ici.

J'adresse tous mes remerciements à l'équipe de développement web pour leurs relectures et leurs conseils.