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.
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.
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
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
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: