README.markdown

Rails migrations in non-Rails (and non Ruby) projects.

WHAT'S NEW

In the 1.0.x release we have moved to using Rails 3 migrations instead of maintaining our own migration related code. Just about anything you can do with Rails 3 migrations you can now do with Standalone Migrations too! This removed 95% of the code we have to maintain. Big thanks to Michael Grosser for undertaking this major rewrite!

CONTRIBUTE

Standalone Migrations relies on the contributions of the open-source community! To submit a fix or an enhancement fork the repository, checkout the develop branch, make your changes, add your name to the Contributors section in README.markdown, and send us a pull request! If you're active and do good work we'll add you as a collaborator!

To migrate to a specific version (for example to rollback)

To migrate a specific database (for example your "testing" database)

To execute a specific up/down of one single migration

rake db:migrate:up VERSION=20081220234130

To revert your last migration

rake db:rollback

To revert your last 3 migrations

rake db:rollback STEP=3

Custom configuration

By default, Standalone Migrations will assume there exists a "db/"
directory in your project. But if for some reason you need a specific
directory structure to work with, you can use a configuration file
named .standalone_migrations in the root of your project containing
the following:

These are the configurable options available. You can omit any of
the keys and Standalone Migrations will assume the default values.

Changing environment config in runtime

If you are using Heroku or have to create or change your connection
configuration based on runtime aspects (maybe environment variables),
you can use the StandaloneMigrations::Configurator.environments_config
method. Check the usage example:

You have to put this anywhere on your Rakefile. If you want to
change some configuration, call the #on method on the object
received as argument in your block passed to ::environments_config
method call. The #on method receives the key to the configuration
that you want to change within the block. The block should return
your new configuration hash or nil if you want the configuration
to stay the same.

Your logic to decide the new configuration need to access some data
in your current configuration? Then you should receive the configuration
in your block, like this: