french Available Tasks - Azema/Phigrate GitHub Wiki

#Tâches disponibles

Une des choses cool du framework est son soutien pour l'écriture de tâches personnelles. En fait, le but principal du framework, les migrations, est juste une tâche simple.

Une tâche basique qui initialise votre BDD pour permettre les migrations. Vous devez toujours lancer cette tâche lorsque vous démarrez votre projet.

Nom de la tâche: db:setup

Usage:

    phigrate db:setup

Voici à quoi devrait ressembler la sortie:

    Started: 2007-09-03 9:34pm PDT

    [db:setup]: 
            Creating table: schema_migrations
            Done.

    Finished: 2007-09-03 9:34pm PDT

Cette tâche créera la table schema_migrations dans votre BDD avec une seule colonne, version qui est utilisée pour connaître la version courante de votre BDD.

Le but principal du framework est de lancer les migrations, et l'exécution de toutes les migrations est dirigée par une seule tâche.

Nom de la tâche: db:migrate

Usage:

    phigrate db:migrate

Options: Un paramètre VERSION peut être spécifié pour monter (ou descendre) à une version spécifique, basée sur la version courante. Si elle n'est pas spécifiée, toutes les migrations supérieures à la version courante en base de données seront exécutées.

Exemple A: La base de données est nouvelle et donc vide, en supposant qu'il y a 5 fichiers de migration, mais seulement la première d'entre elles doit être lancée.

    phigrate db:migrate VERSION=20101006114707

Voici à quoi devrait ressembler la sortie:

    ...snip...

    [db:migrate]: 
            Migrating UP to: 20101006114707 (current version: 0)

    ...snip...

Exemple B: La version courante de la BDD est 20101006114707 et nous voulons redescendre à la version 20100921114643

    phigrate db:migrate VERSION=20100921114643

Voici à quoi devrait ressembler la sortie:

    ...snip...

    [db:migrate]: 
            Migrating DOWN to: 20100921114643 (current version: 20101006114707)

    ...snip...

Example C: Vous pouvez aussi utiliser un numéro de révision relatif (positif permet de monter, negatif permet de descendre).

    phigrate db:migrate VERSION=-2

Le but principal du framework est de lancer les migrations, mais vous pouvez aussi exporter le code SQL généré par les migrations. Cette tâche se comporte exactement de la même manière que db:migrate à la seule différence qu'il n'exécute pas le code SQL mais vous le retourne sur la sortie standard.

Nom de la tâche: db:export

Usage:

    phigrate db:export

Options: Un paramètre VERSION peut être spécifié pour monter (ou descendre) à une version spécifique, basée sur la version courante. Si elle n'est pas spécifiée, toutes les migrations supérieures à la version courante en base de données seront exportées.

Exemple:

    phigrate db:export VERSION=2

Voici à quoi devrait ressembler la sortie:

--
--	Export SQL by Phigrate
--

-- Started: 2012-09-09 2:08pm CEST

-- [db:export]:
--	Migrating UP:


    ...snip...

Il est toujours possible de demander à Phigrate (en réalité la BDD) à quelle version nous sommes actuellement.

Nom de la tâche: db:version

Usage:

    phigrate db:version

Voici à quoi devrait ressembler la sortie:

    ...snip...

    [db:version]: 
            Current version: 2

    ...snip...

Avec cette tâche, nous obtenons un aperçu des migrations exécutées et celles qui sont en attente d'une nouvelle migration.

Nom de la tâche: db:status

Usage:

    phigrate db:status

Voici à quoi devrait ressembler la sortie:

    ...snip...

    [db:status]: 

            ===================== APPLIED ======================= 
                Test12 [ 20110615090336 ]
            
            ===================== NOT APPLIED ======================= 
                CreateUsersTable [ 20110615093413 ]
            
    ...snip...

Il peut être bénéfique pour obtenir un dump de la BDD au format SQL brut qui représente la version actuelle. _Note: _ Ce dump contient uniquement le schéma actuel (par exemple, le DML nécessaire pour reconstruire la base de données), mais pas les données. En termes de MySQL, cette tâche ne serait pas être la même que l'exécution de la commande mysqldump (qui par défaut contient toutes les données des tables).

Nom de la tâche: db:schema

Usage:

    phigrate db:schema

Cette tâche génère un fichier nommé db/schema.txt qui contient le code SQL nécessaire pour re-générer le schéma.

NOTE: Cette tâche délègue à l'adaptateur de votre SGBDR car le contenu de db/schema.txt est susceptible d'être très spécifique au SGBDR.

Toutes les tâches suivent un nommage et une structure conventionnelle. C'est cette structure et son placement dans le répertoire lib/tasks qui permet au framework de retrouver automatiquement les tâches et les enregistre pour les utiliser.

En un mot, le nom des tâches sont des pseudo espace de noms. Les tâches qui fournies avec le framework sont définies avec l'espace de nom "db" (e.g. les tâches sont "db:migrate", "db:setup", etc...).

Basé sur cette structure, les noms de fichiers des tâches ont la partie de l'espace de nom en majuscule, suivi par le reste, avec sa première lettre en majuscule.

Exemples:

• db:migrate is named Task_Db_Migrate.php
• db:setup is named Phigrate_Db_Setup.php

Toutes les tâches doivent implémenter l'interface Phigrate_Task_ITask.php, qui actuellement n'a qu'une seule méthode: execute().

Votre méthode execute() peut faire ce que vous voulez.

Le framework mettra automatiquement à votre disposition un objet représentant l'adaptateur du SGBDR via la propriété privée _adapter.

Par exemple:

    $result = $this->_adapter-> ... 

Si vous avez nommé votre tâche selon les conventions ci-dessus et que votre tâche implémente l'interface ITask et que le fichier de la tâche est placé dans Tasks alors votre tâche sera automatiquement accessible et de ce fait exécutable via le wrapper phigrate.

Par exemple, disons que vous avez écrit un fichier de tâche avec le nom Task_Fs_Hello.php, il est placé dans le répertoire Tasks/Fs, alors elle devrait être disponible via:

    phigrate fs:hello