While developing, Doctrine Migrations can quickly become obsolete as you adjust your schema in the early stages of development. Nevertheless, Migrations are still a vital part of properly building compatibility for deployments. However, to consolidate and avoid having several (or in my case dozens) Migration Versions before you’ve got a stable schema, I’ve found it very useful to “rebase” my migrations to a single file.
I also try to keep my non entity driven schemas in a separate file, typically Version0.php. All of my recent development work has been on Symfony 2.7 so I have a modified sessions table I use for PDO session management (that’s a separate debate we can have later). This particular file I want to ignore when running this script so I’m left with two consolidated files for my entire schema:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
#!/bin/bash # symfony-rebase-migrations.sh # Include the global config file DIR=$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd ) source $DIR/config echo "Removing old baseline Migration version" cd /var/www/$APPNAME/www/app/DoctrineMigrations find . -type f -not -name "Version0.php" -exec rm -rf {} \; cd /var/www/$APPNAME/www php app/console doctrine:generate:entities YOUR_BUNDLE_NAME php app/console doctrine:database:drop --force php app/console doctrine:database:create php app/console doctrine:migrations:diff cd /var/www/$APPNAME/www sudo php app/console cache:clear |
And last but not least, this simply bash script calls upon a file config in the same source directory that has simple configuration values:
|
1 2 3 4 5 |
APPNAME=litwicki DBHOST=127.0.0.1 DBNAME=litwicki DBUSER=root DBPASSWD=litwicki |
Usage
Simply run the bash script above and your Migrations files will be cleaned up entirely. You’ll of course want to rebuild your database as well so everything is in sync.
|
1 |
$ sudo bash /path/to/symfony-rebase-migrations.sh |
Symfony Tools
This is one script available in a collection of simple scripts I’ve written to help my development
