Until Lotus supports migrations out of the box you have to roll your own solution.1 Thankfully this is not so difficult, let me show you how to do it. The following setup will actually work in any Ruby project that already leverages Sequel. In the end you will have following things:
- A place to store your migration files.
- A Rake task to run the migrations.
- A Rake task to rollback the last migration.
The projects Rakefile
is the place to start. First you tell Rake where to find your custom Rake tasks and then you add an environment
task on which other tasks can depend upon. This task is responsible for loading the applications environment. Your migration tasks need the environment in order to know which database should be used for the migrations.
The environment task uses Lotus::Application.preload!
to load the Lotus environment. This does not load any of your application code. If you want to load the application code use Lotus::Application.preload_applications!
but be aware of the healthy migration habits and don't rely on application specific code in your migrations.
Both the migrate
and rollback
tasks are heavily inspired by the official Sequel migrations guide. The tasks depend on the environment
task you wrote earlier and require the Sequel gem with the migration extension. In order to run all migrations you need a connection to a database and a directory where the migrations are stored.
The environment variable DATABASE_URL
is used to connect to the database, make sure to change this so it matches your own project environment. Your migrations are supposed to be in the db/migrations
directory.
Rolling back a migration is a little more complicated. You need to tell Sequel a target version you want to roll back to. Since you want to roll back a single version per rollback
invocation you can automate the process of finding the correct version. Be aware that Sequel supports an IntegerMigrator
and a TimestampMigrator
. There are a few differences but for the task at hand only two are relevant: The naming of the migration files and where Sequel stores information about the schema.
This article focuses on the TimestampMigrator
, therefore the schema information is stored in the schema_migrations
table which can be queried to find the second to last migration. Then you have to extract the version, that's the timestamp at the beginning, from the filename. Once you have determined the version you can use the same command as in the migrate task and provide an additional target
argument.
Having all this in place the only thing left to do for you is writing migrations. Sequel has an excellent documentation on what schema modifications are possible and the migrations guide will help you understand what can be done in a migration.
You can run your migrations with bundle exec rake db:migrate
and roll back the last migration with bundle exec rake db:rollback
.
An example migration with this setup might look like this: