Minimal Migration Manager
Usage: ./mmm [-h] [-f config_file] command [command options...] Options: -h Show this message. -f config_file Configuration file to use. (defaults to ./mmm.conf) Commands: init [config] Create a new migration directory and config file unless 'config' is specified, which creates a config file only. seed <seed file> Seed the database with a .sql file. head Get the latest local revision. pending List all migrations yet unapplied. migrate Apply all pending migrations. rollback [revision] Unapply all migrations since <revision> which defaults to the current previous revision. assimilate Track an existing database, assuming that all migrations have been applied.
mmm is a simple database schema management tool using plain SQL
files to represent changes in the schema, and one tracking table
to track the current state.
To quickly get up and running, do the following:
- Create your database
mmm initto create the config and migration directory.
- Edit the generated config.
- If you have a seed file, run it with
- Otherwise, run
mmm assimilateto create the state table.
- Add your migrations to the migration directory.
mmm migrateto run them.
Note that your first batch of migrations won't record a previous revision
as there is no previous revision to record, if you create your database
by way of the
seed command. However,
assimilate will record
the local revision.
Required (at least one of these):
libsqlite3for SQLite3 support.
libpqfor PostgreSQL support.
libmysqlclientfor MySQL support.
Dependencies will be selected by default if they're available in
the prefix specified to
configure. You can specify the paths
for these dependencies yourself by passing the following options:
--with-sqlite3=PATH enable support for SQLite3 --with-pgsql=PATH enable support for PostgreSQL --with-mysql=PATH enable support for MariaDB / MySQL --with-libgit2=PATH enable git support via libgit2 --with-cunit=PATH enable support for CUnit
--without- argument will prevent
mmm from being
built with that particular dependency.
mmm, simply check-out the sources, and do a
./configure && make && make install.
Alternatively, you can also run the automated tests, and generate a coverage report.
- To run the tests:
- To generate a coverage report:
make clean coverage
- To uninstall:
If you have issues running
./autogen.sh and try
The configuration file is a typical ini-style configuration file,
See the default file generated by
mmm init for an explanation of
the options, although they should be self-explanatory.
Three database drivers are available:
mysql, and are usable assuming the aforementioned dependencies
sqlite3 only the
db option need be specified, and it should
be the path to the SQLite3 database to use.
mysql all other options should also be specified.
To use a UNIX socket with these two, set the
host option to the
path to the socket, and
port to 0. The client character set will
default to UTF-8.
mysql defaults will be read from the mysql section of the
config file for any unspecified parameters.
The migration files are plain SQL files, split into two sections like so:
-- [up] CREATE TABLE test(id INTEGER NOT NULL); -- [down] DROP TABLE test;
upsection contains the SQL queries to run when applying a migration.
downsection contains the SQL queries to run when rolling back a migration.
They can be specified in either order.
Two sources are currently supported:
file source looks at the files in the specified
migration_path in order to determine the order that the
files should be applied. This source assumes that all migrations
begin with a numeric designation, for example:
and will be arranged in numerical order. This is the default
source. Revisions correspond to the files' designations.
git source uses a git repository for determining the order
in which migrations should be applied. With this source, the files
need not have a numeric designation, and they will be applied in
the order in which they were committed to the repository. Revisions
correspond to the actual SHA1 hash for the commit at which the
current aet of migrations was performed.
git source requires libgit2.
mmm can only handle files smaller than 64 KB by default. To raise
this limit, increase
FILEBUFSIZ in src/file.c
mmm uses transactions to ensure that if an error occurs, the
database is returned to a known state. However, not all RDMBS support
transactional DDL (Data Definition Language) statements, and therefore
mmm cannot guarantee that databases on these RDBMS systems will be
in the desired state when rolling back the transaction.
If an error occurs, and your database lacks transactional DDL support, mmm will emit an error message advising you of the situation. In these cases, you will need to manually verify that your schema is correct.
In case of upgrading the schema,
mmm will automatically roll back
any applied migrations in the current batch when an error occurs if the
RDBMS lacks transactional DDL support.
MySQL is supported, although you should be aware that any DDL commands
will cause an implicit commit. Thus, when writing migrations, you should use
IF [NOT] EXISTS on your
DROP statements to
ensure that migrations can still run if, for example, and added table
could not be successfully dropped on rollback.