Skip to content

french Configuration

Jump to bottom
Manuel Hervo edited this page Sep 10, 2012 · 9 revisions

Configuration

Application

Pour un fonctionnement optimal, vous pouvez renseigner les informations de configuration du framework Phigrate dans le fichier de configuration, exemple: config/application.ini.

Un fichier modèle est disponible dans le répertoire config. Copiez le au même endroit avec le nom donné ci-dessus.

Voici les options de configuration disponibles:

Paramètre Valeurs possibles Description Obligatoire
database.conf Chemin absolu / relatif Correspond au chemin d'accès au fichier de configuration des bases de données. Si vous spécifiez un chemin relatif, c'est le répertoire du fichier de configuration principal qui servira de base. Non
task.dir Chemin absolu Correspond au répertoire des tâches que vous lancez avec le fichier phigrate. Par défaut, il s'agit du répertoire Task dans la librairie du framework. Cependant, si vous souhaitez développer vos propres tâches, vous pourrez ainsi indiquer le chemin de vos tâches. Non
migration.dir Chemin absolu / relatif Correspond au répertoire où seront écrits les fichiers de migration. Si vous spécifiez un chemin relatif, c'est le répertoire du fichier de configuration principal qui servira de base. Oui
log.dir Chemin absolu / relatif Correspond au répertoire où seront écrits les logs. (Attention aux droits d'écriture) Si vous spécifiez un chemin relatif, c'est le répertoire du fichier de configuration principal qui servira de base. Oui
log.priority Int (1 à 4) 4 étant le plus verbeux Correspond à la priorité de log que vous souhaitez voir dans votre fichier de logs. Les priorités vont de 1 à 4, 1 étant seulement les erreurs et 4 étant le plus verbeux. Non
debug Boolean (0 / 1) Comme son nom l'indique, il permet d'activer ou non le mode debug. Non

Votre fichier devra obligatoirement comporter une section pour chaque environnement que vous souhaiterez migrer.

Il vous est possible de créer un fichier .rucku à la base de votre projet. Ce fichier est le fichier de configuration principal. Pour ma part, je crée un lien symbolique vers le vrai fichier de configuration.

Ce fichier vous permet d'appeler Phigrate n'importe où dans votre projet.

Base de données

Pour spécifier la base de données qui recevra les migrations, vous devez renseigner les informations de connexion pour chaque environnement à migrer, dans un fichier, exemple: config/database.ini.

Comme pour le fichier de configuration de l'application, un fichier modèle est disponible dans le répertoire config. Il vous faudra également une section par environnement que vous souhaiterez migrer.

Voici les options disponibles:

Paramètre Valeurs Description Obligatoire
type mysql Le type de base de données Oui
host IP ou Nom L'hôte du serveur Oui
port Integer Le port du serveur Non
socket Chemin absolu La socket du serveur. Soit vous spécifier l'hôte, soit la socket. La socket sera privilégiée. Non
database String Le nom de la base de données. Oui
user String Le nom de l'utilisateur de la base de données. Non
password String Le mot de passe de l'utilisateur. Non

Bien entendu, vous n'avez pas besoin de renseigner toutes les informations. Soit l'hôte et optionnellement le port ou bien la socket. Le choix de la socket sera privilégié. Cependant, vous avez quand même besoin de renseigner le nom de la base de données et l'utilisateur, bien que l'utilisateur ne soit pas obligatoire, je vous le recommande fortement, idem pour le password.

Les options de configuration des scripts

phigrate

Vous retrouverez les paramètres de configuration dans les arguments du script phigrate. Les arguments du script surchargent ceux du fichier de configuration. Pour obtenir les arguments à passer au script, vous pouvez appeler le script sans arguments ou bien avec l'argument help. Vous devriez obtenir une sortie semblable à celle ci-dessous.

Si vous éclater le framework Phigrate, il vous faudra renseigner au minimum le fichier de configuration lors de l'appel au script phigrate. Quand je parle d'éclater, je veux dire que la librairie se trouve par exemple dans le répertoire /usr/share/pear/, la config dans /etc/phigrate/ et les scripts dans /usr/bin/. Sauf si vous utilisez le fameux fichier .rucku à la base de votre projet (Voir plus haut).

Par défaut, le framework tente de récupérer le fichier de configuration dans ./config/application.ini et celui de la base de données dans ./config/database.ini.


Usage: phigrate [options] [help] [ENV=environment] <task> [task parameters]

Options:
    -c, --configuration  Path to the configuration file (INI) of application.

    -d, --database       Path to the configuration file (INI) of databases.

    -t, --taskdir        Path of the directory of the tasks.

    -m, --migrationdir   Path of the directory of the migrations.

    -l, --logdir         Path to the logs file.

###########

    help: Affiche ce message

    help <task>: Display help of <task>

    ENV: The ENV command line parameter can be used to specify a different
database to run against, as specific in the configuration file (config/database.inc.php).
By default, ENV is "development"

    task: In a nutshell, task names are pseudo-namespaced. The tasks that come
with the framework are namespaced to "db" (e.g. the tasks are "db:migrate", "db:setup", etc).
All tasks available actually :

     - db:setup : A basic task to initialize your DB for migrations is
     available. One should always run this task when first starting out.

     - db:migrate : The primary purpose of the framework is to run migrations,
     and the execution of migrations is all handled by just a regular ol' task.

     - db:export : The main purpose of the framework is to initiate the migration, 
     but you can also export the SQL generated by migration.

     - db:version : It is always possible to ask the framework (really the DB)
     what version it is currently at.

     - db:status : With this taks you'll get an overview of the already
     executed migrations and which will be executed when running db:migrate

     - db:schema : It can be beneficial to get a dump of the DB in raw SQL
     format which represents the current version.
For more documentation on the tasks
@see https://github.com/Azema/ruckusing-migrations/wiki/Available-Tasks

Call with no arguments to see usage info.

Désolé pour les francophones, mais le script est en anglais, ainsi que les sources.

Clone this wiki locally