Warning: this package is no longer actively maintained, and
unfortunately I do not have plans to resume maintenance. This package
is very old; in fact, it's the first Haskell package I published, and
it shows in many ways. I also don't use it nowadays, which doesn't
help when it comes to maintenance. If you are using this library in
production, just keep this in mind and I encourage you to consider
alternatives. If you would like to take over maintenance, please
consider forking this and letting me know at cygnus AT foobox DOT com
so I can update the Hackage deprecation status in favor of your new
package.
This package contains a library for the creation, management, and installation of schema updates (called "migrations") for a relational database. In particular, this package lets the migration author express explicit dependencies between migrations. This library is accompanied by a number database-specific packages that contain the management tools to automatically install or revert migrations accordingly.
This package operates on two logical entities:
-
The "backend": the relational database whose schema you want to manage.
-
The "migration store": the collection of schema changes you want to apply to the database. These migrations are expressed using plain text files collected together in a single directory, although the library is general enough to permit easy implementation of other storage representations for migrations.
To get started, install the right database-specific dbmigrations package for your database. Current options are:
dbmigrations-postgresqldbmigrations-mysqldbmigrations-sqlite
Each package provides a variant of the "moo" management program ("moo-postgresql", "moo-mysql", and "moo-sqlite" respectively) to be used to manage your database schema. See MOO.TXT for details on how to use these tools to manage your database migrations.
I'll gladly consider accepting patches to this package; please do not hesitate to submit GitHub pull requests. I'll be more likely to accept a patch if you can follow these guidelines where appropriate:
-
Keep patches small; a single patch should make a single logical change with minimal scope.
-
If possible, include tests with your patch.
-
If possible, include haddock with your patch.