percolate:migrations
A simple migration system for Meteor supporting up/downwards migrations and command line usage. There is also a fork available for use outside of Meteor.
Installation
Meteor Migrations can be installed through Meteor's package manager. Type:
$ meteor add percolate:migrations
API
Basics
To write a simple migration, somewhere in the server section of your project define:
1Migrations.add({ 2 version: 1, 3 up: function() {//code to migrate up to version 1} 4});
To run this migration from within your app call:
1Meteor.startup(() => { 2 Migrations.migrateTo('latest'); 3});
Advanced
A more complete set of migrations might look like:
1Migrations.add({ 2 version: 1, 3 name: 'Adds pants to some people in the db.', 4 up: function() {//code to migrate up to version 1} 5 down: function() {//code to migrate down to version 0} 6}); 7 8Migrations.add({ 9 version: 2, 10 name: 'Adds a hat to all people in the db who are wearing pants.', 11 up: function() {//code to migrate up to version 2} 12 down: function() {//code to migrate down to version 1} 13});
As in 'Basics', you can migrate to the latest by running:
1Meteor.startup(function() { 2 Migrations.migrateTo('latest'); 3});
Note: Migrations should be run from Meteor.startup
to allow for log output configuration.
By specifying a version, you can migrate directly to that version (if possible). The migrations system will automatically determine which direction to migrate in.
In the above example, you could migrate directly to version 2 by running:
1Migrations.migrateTo(2);
If you wanted to undo all of your migrations, you could migrate back down to version 0 by running:
1Migrations.migrateTo(0);
Sometimes (usually when somethings gone awry), you may need to re-run a migration. You can do this with the rerun subcommand, like:
1Migrations.migrateTo('3,rerun');
NOTE: You cannot create your own migration at version 0. This version is reserved by migrations for a 'vanilla' system, that is, one without any migrations applied.
To see what version the database is at, call:
1Migrations.getVersion();
Configuration
You can configure Migrations with the config
method. Defaults are:
1Migrations.config({ 2 // Log job run details to console 3 log: true, 4 5 // Use a custom logger function (defaults to Meteor's logging package) 6 logger: null, 7 8 // Enable/disable logging "Not migrating, already at version {number}" 9 logIfLatest: true, 10 11 // migrations collection name to use in the database 12 collectionName: "migrations" 13});
Logging
Migrations uses Meteor's logging
package by default. If you want to use your
own logger (for sending to other consumers or similar) you can do so by
configuring the logger
option.
Migrations expects a function as logger
, and will pass arguments to it for
you to take action on.
1var MyLogger = function(opts) { 2 console.log('Level', opts.level); 3 console.log('Message', opts.message); 4 console.log('Tag', opts.tag); 5} 6 7Migrations.config({ 8 logger: MyLogger 9}); 10 11Migrations.add({ name: 'Test Job', ... });
The opts
object passed to MyLogger
above includes level
, message
, and tag
.
level
will be one ofinfo
,warn
,error
,debug
.message
is something likeFinished migrating.
.tag
will always be"Migrations"
(handy for filtering).
Custom collection name
By default, the collection name is migrations. There may be cases where this is inadequate such as using the same Mongo database for multiple Meteor applications that each have their own set of migrations that need to be run.
Command line use
*** DEPRECATED ***
This info is for pre 0.9 users as post 0.9 the migrate.sh
script is no longer included in the package folder.
You can also run migrations from the command line using the included shell script. This will
- Launch your Meteor app
- Call
Migrations.migrateTo(version)
- Exit your app
For instance, from your project's root, run:
$ ./packages/percolatestudio-migrations/migrate.sh latest
You can also specify additional arguments to be passed into meteor, like:
$ ./packages/percolatestudio-migrations/migrate.sh latest --settings ./setting.json
Errors
Not migrating, control is locked
Migrations set a lock when they are migrating, to prevent multiple instances of your clustered app from running migrations simultaneously. If your migrations throw an exception, you will need to manually remove the lock (and ensure your db is still consistent) before re-running the migration.
From the mongo shell update the migrations collection like this:
$ meteor mongo db.migrations.update({_id:"control"}, {$set:{"locked":false}}); exit
Alternatively you can unlock the collection from either server code or the meteor shell using:
Migrations.unlock();
Contributing
-
Write some code.
-
Write some tests.
-
From this package's local directory, start the test runner:
$ meteor test-packages ./
-
Open http://localhost:3000/ in your browser to see the test results.
License
MIT. (c) Percolate Studio, maintained by Zoltan Olah (@zol).
Meteor Migrations was developed as part of the Verso project.