french Configuration - Azema/Phigrate GitHub Wiki
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.
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.
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.