Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

The Art of Doctrine Migrations


Published on

Doctrine Migrations presentation from the nasvhille symfony user group - February 2010

Published in: Technology
  • @beachDefender-

    I don't exactly what problem you're getting at, but I do know that there are definitely issues with Doctrine1 (and Doctrine1's migrations) related to the naming of things, how versions are tracked etc. In fact, the importance of this presentation is really to highlight how you can use a system that's far from perfect to solve a problem.

    The better answer is this: Symfony2 and Doctrine2 are different. The Doctrine migrations now exist as a standalone library from the Doctrine community and - while not yet stable - is very well done (the design takes a lot from other languages and how they solve the problem of migrations). Symfony2 is much the same way - nothing is imposed on you and where there *are* standards, they exist only for convenience and you're free to use whatever standard you want.

    So, if you're frustrated by some issues or conventions with Doctrine1 or symfony1, I'd encourage you to have a look at Doctrine2 and Symfony2 - a lot of work has been done to learn from the first versions.

    And if I totally missed your question/comment, let me know :)
    Are you sure you want to  Yes  No
    Your message goes here
  • Why have you done so little to use scope rather than naming conventions to avoid conflict? There is simply no good reason that I cant have a table name the same as an index name as a column name as a foreign key.

    To rely on something as fickle and abstract as a naming convention rather than scope to avoid conflict essentially renders the application useless as a serious, enterprise building tool.

    I am not encouraged by the insistence in both Doctrine and Symfony on this approach. It might work for small, simple databases and systems but basing internal structures based on a name rather than a definition is a really bad design choice.

    You throw out all the flexibility of underlying systems and make it almost impossible to build large multi application environment effectively and efficiently.

    Each of the components in the layer - RDBMS, PHP, and even the file system, understand scope, none of them care about naming.
    Are you sure you want to  Yes  No
    Your message goes here
  • hey Ryan, so i changed my deploy scripts, but i still have a problem. from my staging server where i do generate the migratons-diff I do:

    - ssh prodserver symfony project:disable prod
    - symfony project:deploy prod --go
    - ssh prodserver symfony doctrine:migrate --env=prod
    - ssh prodserver symfony project:clear-controllers
    - ssh prodserver symfony project:permissions
    - ssh prodserver symfony project:enable prod

    the only problem is that when i do the doctrine:migrate i get the temporary unavailable page. i launch my commands like this:
    - ssh produser@localhost ’~/ project:enable prod’ thanks a lot
    Are you sure you want to  Yes  No
    Your message goes here
  • Ok I see, thanks. So i'll generate the migration classes on my staging server and then deploy to production.

    thanks a lot again
    Are you sure you want to  Yes  No
    Your message goes here
  • It's even more to make sure that you didn't forget to generate any migrations. For example, suppose you added a column and then regenerated your model. You then add another column, run the diff tool (as you should) and then regenerate the model. The generated diff will only contain the second column you added - there will be no migration for the first. Using the mysql diff tool is a low-level way to detect if you missed anything.
    Are you sure you want to  Yes  No
    Your message goes here

The Art of Doctrine Migrations

  1. 1. Nashville symfony Group The Art of Doctrine Migrations Feb 2nd, 2010 Ryan Weaver @weaverryan
  2. 2. Nashville symfony Group Feb 2010 So you've updated your code, now to update your database...  PhpMyAdmin: post-it notes, pizza & beer  SQL deltas:  Pros: familiar syntax, tools available  Cons: not systematic, db-specific, disconnected from ORM  Doctrine Migrations:  Pros: systematic, generate automatically, written in Nashville (probably)  Cons: were a pain in the ass (until now), still a bit quirky
  3. 3. Nashville symfony Group Feb 2010 A PHP file with simple directions on how to update your database Each file is prefixed by a number, which determines its ordering: /lib/migration/doctrine/  1_add_brilliant_idea_table.php  2_add_good_people_table.php  3_add_desc_field_to_idea.php
  4. 4. Nashville symfony Group Feb 2010 Tracking Versions Doctrine keeps track of your db's “version” via migration_version table /lib/migration/doctrine/  1_add_brilliant_idea_table.php version 1  2_add_good_people_table.php version 2  3_add_desc_field_to_idea.php version 3  4_modify_some_column.php version 4  35_alternatively_numbered.php version 5
  5. 5. Nashville symfony Group Feb 2010 Take a deep breath and migrate: ./symfony doctrine:migrate [migration #]
  6. 6. Nashville symfony Group Feb 2010 Writing Migrations Create a blank migration file: doctrine:generate-migration name  Creates a blank file in lib/migration/doctrine (e.g. 1265085881_add_another_table.php)  Use the rich API to make changes Cheat-Sheet-1.1.pdf
  7. 7. Nashville symfony Group Feb 2010 Or just generate the migrations automatically...
  8. 8. Nashville symfony Group Feb 2010 Generate Migrations For an existing database & project with no migrations: doctrine:generate-migrations-db • Generates migration classes for everything to date • For example, for a project with 75 tables, this would generate 76 migration classes • (1 per table + 1 giant class for all indexes and foreign keys) This gets you “caught up”, but only works once.
  9. 9. Nashville symfony Group Feb 2010 Migration-diff tool Generates new migration class(es) based on some schema change 1) Make a change to your schema (e.g. add a column) 2) Run the diff tool task: doctrine:generate-migrations-diff 3) Rebuild your model doctrine:build --all This runs a “diff” between your new schema and your old model files. Lame/Warning: If you rebuild your model before running the diff tool, no changes will be recognized
  10. 10. Nashville symfony Group Feb 2010 Filename Conventions Generated migrations take one of these 2 forms: 263866565_migration_name.php 263866565_version15.php We recommend renaming to include the version #: version1_migration_name.php 263866565_version15.php
  11. 11. Nashville symfony Group Feb 2010 Model Name Conventions Generated migrations take one of these 2 forms: class Version15 class MigrationName We recommend naming the class by the version #: class Version 15
  12. 12. Nashville symfony Group Feb 2010 Data Migrations – easy, but... Also can use: - preUp() - preDown() This will break eventually, when you make changes to the BrilliantIdea model (e.g. in 2 months, you remove the name field)
  13. 13. Nashville symfony Group Feb 2010 Doctrine Migration – Ruining your day 1) NEVER mix foreign-key changes with table or column changes Major $this->createTable('brilliant_idea',...) migration $this->createForeignKey('brilliant_idea', …) foul 2) If you care, be careful with your index names Name 'product_slug' becomes 'product_slug_idx'
  14. 14. Nashville symfony Group Feb 2010 Tools – MySQLdiff ( • Simple: compares two databases and gives you a list of their differences – build-all-reload your main database – Migrate your test database
  15. 15. Nashville symfony Group Feb 2010 Discussion Notes from the Presentation Migration Failures Suppose you're migrating from version 2-10 and migration #5 fails: ● Migrations 6-10 will continue to try to run ● The migration_version table will still be set to 2 after the migration, even though versions 3 & 4 were successful
  16. 16. Nashville symfony Group Feb 2010 Discussion Notes from the Presentation generate-migrations-db ● In theory, this task compares your db to your models and generate migrations based on the difference. ● After weeks of dev, all migrations could be generated at once ● At least 2 bugs exist in this task: ● ● Models prefixed with a lowercase letter will not work. But, this does not affect most MACs
  17. 17. Nashville symfony Group Feb 2010 Discussion Notes from the Presentation Resetting your migrations ● To battle “broken” migrations that result from data migrations that reference no-longer-used fields, it may be a good idea to adopt a strategy of periodically “resetting” your migrations: ● Delete all migration files ● Run doctrine:generate-migrations-db ● Manually set your migration_version number to the last, newly-generated migration file
  18. 18. Nashville symfony Group Feb 2010 Discussion Notes from the Presentation Autoloading Bugs in generate-migrations-diff ● When using the diff tool, you may get an error such as: “Cannot find class PrfxSomeClass” ● The diff tool generates temporary models and in some cases (specifically doctrine model subclassing) will require the files in the wrong order ● There is a hack (try the autoload.yml hack): ● http://trac.symfony-
  19. 19. Nashville symfony Group Feb 2010 Questions? Idea Bubbles? Ryan Weaver @weaverryan