Outdated egg!
This is an egg for CHICKEN 4, the unsupported old release. You're almost certainly looking for the CHICKEN 5 version of this egg, if it exists.
If it does not exist, there may be equivalent functionality provided by another egg; have a look at the egg index. Otherwise, please consider porting this egg to the current version of CHICKEN.
nomads
TOC »
Introduction
This extension provides a simple framework for database migrations similar to those used in web frameworks like Ruby on Rails. It allows the user to keep different versions of database-schemas and manage the up- and down migration in a convenient manner.
The library aims to be simple to use, yet powerful enough to do more sophisticated migrations.
For a little explanation on how it came into existence see http://lisp-unleashed.blogspot.com/2010/12/simple-database-migrations-for-chicken.html
Examples
Suppose you have project in which you want to manage your database migrations. There is a directory "migrations" which will hold your migrations. So your minimal directory structure looks like this:
/project |--- migrations
You need to place a configuration-file nomads.config in the project's root
/project |--- nomads.config |--- migrations
This configuration-file may looks something like this.
((nomads (migration-directory "migrations") (database (adapter sqlite) (credentials "test.db"))))
You set the path to the migrations, which is intepreted relative to where the config-file lies. Also you specify the database-adapter and credentials.
Now you're set to manage your migrations.
Generate a Migration
In your project's root do
$ nomads generate my-first-migration
This will generate a migration file inside your migration directory. So your project directory might look something like this afterwards.
/project |---- nomads.config |---- migrations |---- 1333037112-my-first-migration
Now edit this file with your migration code. For example with the following:
((UP "CREATE TABLE tests (name string)") (DOWN "DROP TABLE tests"))
Migrate Up
With the above migration you can now run it with:
$ nomads migrate
This will run the migration and inform you about the result.
Migrating Down
You can revert your changes by issueing:
$ nomads migrate -d
This will migrate down.
You can also migrate to a specific version. See the CLI-Documentation for that
CLI-Documentation
Nomads comes with a tiny cli that can be used to manage your migrations. It allows you to generate migrations as well as migrate up and down. A simple nomads -h reveals the following:
Usage: nomads [options] command [options]
Options ======= -c, --configfile=ARG path to the configuration. Default ./nomads.config -h, --help Display this help
Commands ======== generate Generate a new migration file migrate Run the migrations
As you can see, it supports git-style subcommands to do its work.
The configuration
Before you can start using it, you need to tell what database you use and how you want to connect to it. You do that by placing a configuration file in your project's root. The documentation will be read using simple-configuration with evaluation turned off. A sample configuration for sqlite3 may look like this:
((nomads (migration-directory "migrations") (database (adapter sqlite) (credentials "test.db"))))
A sample configuration for postgresql may look like this:
((nomads (migration-directory "migrations") (database (adapter postgresql) (credentials ((host . "127.0.0.1") (user . "testuser") (password . "testpassword") (dbname . "testdb"))))))
- migration-directory: This is the directory, releative to the project's root, where the migrations are located
- database: This section configures the database.
- database/adapter: The adapter to be used. Currently supported are sqlite and postgresql
- database/credentials: The credentials needed for a connection to the database.
Generation
You can issue nomads generate -h to see further options.
$ nomads generate migratione-name
This will generate a migration in the configured migration directory using the timestamped versioning scheme.
Migration
Once you have migrations in place you can use them:
$ nomads migrate -u $ nomads migrate -d $ nomads migrate -v specific-version
This will migrate up, down or to a specific version. The default action is to migrate up. So you don't have to specify that explicitely.
Planned features:
- rollback the last migration
- report the current migration status
- little DSL to to generate DDL statements
API-Documentation
Supported Databases
The library does currently ship with support for sqlite3 through sql-de-lite, and postgresql through postgresql. You can enable the adapter by requiring the library accordingly.
Enabling the postgresql-support
(use nomads nomads-postgresql) (database-credentials '((host . "127.0.0.1") (user . "testuser") (password . "testpassword") (dbname . "testdb")))
Enabling the sqlite-support
(use nomads nomads-sql-de-lite) (database-credentials "/path/to/db")
Migrationfiles
The migrationfiles must match the following layout
((UP "statement1" "statement2" "statementx") (DOWN "statement1down" "statement2down" "statementxdown"))
Depending on the direction, the library will either execute the statements in the DOWN or in the UP section of the file. There are two special kinds of statements.
Lambdas
Those can be used to implement migrations that can not be expressed by simple SQL-statements
((UP ,(lambda (connection) (do-something-difficult connection)) (DOWN "statement1"))
Irreversible Migrations
If a #f is encountered the migration is interpreted as irreversible. An irreversible migration can not be reverted. In such a case, the library stops at this migration and does not attempt to revert earlier migrations.
((UP "statement1") (DOWN #f))
Configuration
There are some parameters that you might want to tweak. There are also some parameters that allow you to tweak the behaviour of the library even more. See the versioning section for details. Most of the time though you'll only have to set two parameters for the library to work properly.
- database-credentialsparameter
Depending on the database-binding you use, this holds the connection-specification that will be passed to the binding's connect-procedure. See the documentation for sql-de-lite and postgresql for details.
- migration-directoryparameter
As the name suggests this parameter specifies where migration files can be found. If this is a relative pathname it will be interpreted relative to the directory in which the configuration file resides.
- error-on-duplicate-migrationsparameter
If this parameter is set to #t (the default) a condition of kind (nomads-error duplicate-version) is signaled.
- error-on-non-existent-migrationparameter
If this parameter is set to #t (the default) a condition of kind (nomads-error non-existent-version) is signaled, if somone attempts to migrate to a version that doesn't exist.
Versioning and filename format
The library allows you to implement your own custom versioning scheme. By default it uses a simple sequential scheme, that simply prefixes every migration with a numeric value. You're free to implement your own versioning scheme, for example to use timestamped versioning.
- filename-patternparameter
- filename-partitionerparameter
- filename-joinerparameter
- versionerparameter
- version?parameter
- version-less?parameter
- version-equal?parameter
- version->stringparameter
- string->versionparameter
The following example sets up a versioning scheme that uses timestamps
(use nomads nomads-sql-de-lite numbers) (versioner (lambda (max-version) (inexact->exact (current-seconds)))) (filename-partitioner (lambda (filename) (let ((parts (string-split filename "-"))) (cond ((null? parts) (cons #f "")) ((string->number (car parts)) => (lambda (num) (cons (number->string (inexact->exact num)) (string-join (cdr parts) "-")))) (else (cons #f filename)))))) (filename-joiner (lambda (version file) (sprintf "~A-~A" version file))) ;;we need to bind it to the number's version of those (version? number?) (define (->number what) (inexact->exact (if (string? what) (string->number what) what))) (version-less? (lambda (l r) (< (->number l) (->number r)))) (version-equal? (lambda (l r) (equal? (->number l) (->number r))))
Generating Migrations
- generate-migration nameprocedure
The procedure generates a migration-stub inside migration-directory with the given name. It returns the full name of the migration-file including the version.
Running Migrations
- migrate #!key (version 'latest) (callback default-callback)procedure
This procedure starts the migration process. It migrates from the currently active version to version. Depending on the active version the migrations run downwards or upwards executing the DOWN and UP portion of the files respectively. After each check-point (a single migration) callback is invoked. If you do not specify this argument the default-handler will just print which migration have been executed along with the status of their execution.
Authors
Repository
This code is kept in a Mercurial repository on Bitbucket.
License
Copyright (c) 2010 David Krentzlin Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.