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.

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.

[parameter] database-credentials

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.

[parameter] migration-directory

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.

[parameter] error-on-duplicate-migrations

If this parameter is set to #t (the default) a condition of kind (nomads-error duplicate-version) is signaled.

[parameter] error-on-non-existent-migration

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.

[parameter] filename-pattern
[parameter] filename-partitioner
[parameter] filename-joiner
[parameter] versioner
[parameter] version?
[parameter] version-less?
[parameter] version-equal?
[parameter] version->string
[parameter] string->version

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

[procedure] (generate-migration name)

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

[procedure] (migrate #!key (version 'latest) (callback default-callback))

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.

 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.