/ 
App-Sqitch-0.50-TRIAL
River stage one • 3 direct dependents • 3 total dependents
/ sqitch

Name

sqitch - Simple database change management

Synopsis

sqitch [<options>] <command> [<command-options>] [<args>]

Description

Sqitch is a VCS-aware database change management application. What makes it different from your typical migration-style approaches? A few things:

No opinions

Sqitch is not integrated with any framework, ORM, or platform. Rather, it is a standalone change management system with no opinions on your database or development choices.

Native scripting

Changes are implemented as scripts native to your selected database engine. Writing a PostgreSQL application? Write SQL scripts for psql. Writing a MySQL-backed app? Write SQL scripts for mysql.

Dependency resolution

Database changes may declare dependencies on other changes. This ensures proper order of execution, even when you've committed changes to your VCS out-of-order.

No numbering

Change deployment is managed by maintaining a plan file. As such, there is no need to number your changes, although you can if you want. Sqitch doesn't much care how you name your changes.

Terminology

change

A named unit of change. A change name must be used in the file names of its deployment and a reversion scripts. It may also be used in a test script file name.

tag

A known deployment state, pointing to a single change, typically corresponding to a release. Think of it is a version number or VCS revision. A given point in the plan may have any number of tags.

state

The current state of the database. This is represented by the most recently-deployed change. If the state of the database is the same as the most recent change, then it is considered "up-to-date".

plan

A list of one or more changes and their dependencies that define the order of deployment execution. The plan is stored in a "plan file," usually named sqitch.plan. Sqitch reads the plan file to determine what changes to execute to change the database from one state to another.

add

The act of adding a change to the plan. Sqitch will generate scripts for the change, which you then may modify with the necessary code (typically DDLs) to actually make, revert, and test the change.

deploy

The act of deploying changes to a database. Sqitch reads the plan, checks the current state of the database, and applies all the changes necessary to either bring the database up-to-date or to a requested state (a change name or tag).

revert

The act of reverting database changes to reach an earlier deployment state. Sqitch reads the list of deployed changes from the database and reverts them in the reverse of the order in which they were applied. All changes may be reverted, or changes may be reverted to a requested state (a change name or tag).

Options

   --plan-file  FILE    Path to a deployment plan file.
   --engine     ENGINE  Database engine.
   --client     PATH    Path to the engine command-line client.
-d --db-name    NAME    Database name.
-u --username   USER    Database user name.
   --host       HOST    Database server host name.
   --port       PORT    Database server port number.
   --uri        URI     Project unique identifier.
   --top-dir    DIR     Path to directory with plan and scripts.
   --deploy-dir DIR     Path to directory with deployment scripts.
   --revert-dir DIR     Path to directory with reversion scripts.
   --test-dir   DIR     Path to directory with test scripts.
   --extension  EXT     SQL script file name extension.
   --dry-run            Execute command without making any changes.
   --etc-path           Print the path to the etc directory and exit.
   --quiet              Quiet mode with non-error output suppressed.
   --verbose            Increment verbosity.
   --version            Print the version number and exit.
   --help               Print a usage statement and exit.
   --man                Print the complete documentation and exit.

Options Details

--plan-file
sqitch --plan-file plan.txt

Path to the deployment plan file. Defaults to ./sqitch.plan. If this file is not present, Sqitch will attempt to read from VCS files. If no supported VCS system is in place, an exception will be thrown. See "Plan File" for a description of its structure.

--engine
sqitch --engine pg

The database engine to use. Supported engines include:

--client
sqitch --client /usr/local/pgsql/bin/psql

Path to the command-line client for the database engine. Defaults to a client in the current path named appropriately for the specified engine.

-d
--db-name
sqitch --db-name widgets
sqitch -d bricolage

Name of the database. For some engines, such as PostgreSQL and MySQL, the database must already exist. For others, such as SQLite, the database will be automatically created on first connect.

-u
--user
--username
sqitch --username root
sqitch --user postgres
sqitch -u Mom

User name to use when connecting to the database. Does not apply to all engines.

--host
sqitch --host db.example.com

Host name to use when connecting to the database. Does not apply to all engines.

--port
sqitch --port 7654

Port number to connect to. Does not apply to all engines.

--uri
sqitch --uri https://github.com/theory/sqitch/

A uniform resource identifier that uniquely identifies the project. Used to generate unique IDs for project changes, and so should be consistently used in the project. Thus it it is probably best set as a local configuration setting (core.uri).

--top-dir
sqitch --top-dir migrations/

Path to directory containing deployment, reversion, and test SQL scripts. It should contain subdirectories named deploy, revert, and (optionally) test. These may be overridden by --deploy-dir, --revert-dir, and --test-dir. Defaults to ./sql.

--deploy-dir
sqitch --deploy-dir db/up

Path to a directory containing SQL deployment scripts. Overrides the value implied by --top-dir.

--revert-dir
sqitch --revert-dir db/up

Path to a directory containing SQL reversion scripts. Overrides the value implied by --top-dir.

--test-dir
sqitch --test-dir db/t

Path to a directory containing SQL test scripts. Overrides the value implied by --top-dir.

--extension
sqitch --extension ddl

The file name extension on deployment, reversion, and test SQL scripts. Defaults to sql.

--dry-run
sqitch --dry-run

Execute the Sqitch command without making any actual changes. This allows you to see what Sqitch would actually do, without doing it. Implies a verbosity level of 1; add extra --verboses for greater verbosity.

--etc-path
sqitch --etc-path

Print out the path to the Sqitch etc directory and exit. This is the directory where the system-wide configuration file lives, as well as deployment script templates.

--quiet

Suppress normal output messages. Error messages will still be emitted to STDERR. Overrides any value specified by --verbose.

--verbose
sqitch --verbose --verbose

A value between 0 and 3 specifying how verbose Sqitch should be. Unless --quiet is specified, the default is 1, meaning that Sqitch will output basic status messages as it does its thing. Values of 2 and 3 each cause greater verbosity. Ignored if --quiet is specified.

--help
sqitch --help

Outputs a brief description of the options supported by sqitch and exits.

--man
sqitch --man

Outputs this documentation and exits.

-V
--version
sqitch --version

Outputs the program name and version and exits.

Sqitch Commands

init

Create the plan file and directories for deploy, revert, and test scripts if they do not already exist. This command is useful for starting a new Sqitch project.

status

*Not yet implemented.

Output information about the current deployment state of a database, including the name of the last deployed change, as well as any tags applied to it. If any changes in the plan have not been deployed, they will be listed separately. Options:

-s
--show

How much information to show. This option may be passed without a -s or --show. Possible values include:

latest

Show only the latest change. This is the default.

tags

Show a list of all deployed tags.

changes

Show a list of all deployed changes.

format

The format to use to display tags or changes, if either are specified via the --show option. The value may be any one of:

oneline
table
log

*Not yet implemented.

Output the complete change history in reverse chronological order. Options:

-t
-s
--change

Show only the specified change, which may be provided as a change name, ID, or tag.

-n
--max-count

Limit the number of changes to show.

--skip

Skip the specified number changes before starting to show the log output.

--since

Show changes more recent than a specific date.

--until

Show changes older than a specific date.

--user

Limit the changes output to ones where the user name matches the specified pattern (regular expression).

--reverse

Output the changes in reverse sort order.

--format

The format to use. The value may be any one of:

short
oneline
full
table
check

*Not yet implemented.

Sanity check the deployment scripts. Checks include:

  • Make sure all deploy scripts have complementary revert scripts.

add

Add a new change.

tag

List tags or tag the latest change.

rework

Rework an existing change.

deploy

Deploy changes.

revert

Revert changes.

test

*Not yet implemented.

Test changes. All SQL scripts in --test-dir will be run. [XXX Not sure whether to have subdirectories for tests and expected output and to diff them, or to use some other approach.]

config

Get and set project, user, or system Sqitch options.

bundle

*Not yet implemented.

Bundle up deployment and reversion scripts and write out plan and configuration files. Configuration properties may be specified under the [bundle] section of the configuration file, or via sqitch config bundle.$property $value command. Options and configuration properties:

--from

Tag to start the plan from. All tags and changes prior to that tag will not be included in the plan, and their change scripts Will be omitted from the bundle directory. Useful if you've rejiggered your deployment changes to start from a point later in your VCS history than the beginning of time. Property name: bundle.from.

--to

Tag with which to end the plan. No changes or tags after that tag will be included in the plan, and their change scripts will be omitted from the bundle directory. Property name: bundle.to.

--destdir

Specify a destination directory. The plan file and deploy, revert, and test directories will be written to it. Defaults to "bundle". Property name: bundle.destdir.

help

Show help for a specific command or, if no command is specified, show the same documentation as --help.

Configuration

Sqitch configuration can be set up on a project, user, or system-wide basis. The format of the configuration file, named sqitch.conf, is the same as for git.

Here's an example of a configuration file that might be useful checked into a VCS for a project that deploys to PostgreSQL and stores its deployment scripts with the extension ddl under the migrations directory. It also wants bundle to be created in the _build/sql directory, and to deploy starting with the "gamma" tag:

[core]
    uri       = https://github.com/theory/sqitch/
    engine    = pg
    db        = widgetopolis
    top_dir   = migrations
    extension = ddl

[revert]
    to        = gamma

[bundle]
    from      = gamma
    tags_only = yes
    dest_dir  = _build/sql

And here's an example of useful configuration in ~/.sqitch/sqitch.conf, to point to system-specific engine information:

[core.pg]
    client    = /usr/local/pgsql/bin/psql
    username  = theory

[core.mysql]
    client    = /usr/local/mysql/bin/mysql
    username  = root

[core.sqlite]
    client    = /usr/local/bin/sqlite3

Various commands read from the configuration file and adjust their operation accordingly. See sqitch-config for a list.

See Also

The original design for Sqitch was sketched out in a number of blog posts:

Other tools that do database change management include:

Rails migrations

Numbered migrations for Ruby on Rails.

Module::Build::DB

Numbered changes in pure SQL, integrated with Perl's Module::Build build system. Does not support reversion.

DBIx::Migration

Numbered migrations in pure SQL.

Versioning

PostgreSQL-specific dependency-tracking solution by depesz.

Author

David E. Wheeler <david@justatheory.com>

License

Copyright (c) 2012 iovation Inc.

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.