=head1 Name

sqitch - Sane database change management

=head1 Synopsis

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

=head1 Description

Sqitch is a database change management application. What makes it different
from your typical L<migration|Module::Build::DB>-L<style|DBIx::Migration>
approaches? A few things:

=over

=item 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.

=item Native scripting

Changes are implemented as scripts native to your selected database engine.
Writing a L<PostgreSQL|http://postgresql.org/> application? Write SQL scripts
for L<C<psql>|http://www.postgresql.org/docs/current/static/app-psql.html>.
Writing a L<MySQL|http://mysql.com/>-backed app? Write SQL scripts for
L<C<mysql>|http://dev.mysql.com/doc/refman/5.6/en/mysql.html>.

=begin comment

=item VCS integration

Sqitch likes to use your VCS history to determine in what order to execute
changes. No need to keep track of execution order; your VCS already tracks
information sufficient for Sqitch to figure it out for you.

=end comment

=item 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.

=item 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.

=begin comment

=item Bundling

Rely on your VCS history for deployment but have Sqitch bundle up changes for
distribution. Sqitch can read your VCS history and write out a plan file along
with the appropriate deployment and reversion scripts. Once the bundle is
installed on a new system, Sqitch can use the plan file to deploy or the
changes in the proper order.

=item Reduced Duplication

If you're using a VCS to track your changes, you don't have to duplicate
entire change scripts for simple changes. As long as the changes are
L<idempotent|http://en.wikipedia.org/wiki/Idempotence>, you can change
your code directly, and Sqitch will know it needs to be updated.

=end comment

=back

=begin comment

Eventually move to L<sqitchtutorial> or L<sqitchintro> or some such.

=end comment

=head2 Terminology

=over

=item C<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.

=item C<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.

=item C<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".

=item C<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
F<sqitch.plan>. Sqitch reads the plan file to determine what changes to
execute to change the database from one state to another.

=item C<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.

=item C<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).

=item C<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).

=back

=head1 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.
     --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.

=head1 Options Details

=over

=item C<--plan-file>

  sqitch --plan-file plan.txt

Path to the deployment plan file. Defaults to F<$top_dir/sqitch.plan>. See
L</Plan File> for a description of its structure.

=item C<--engine>

  sqitch --engine pg

The database engine to use. Supported engines include:

=over

=item * C<pg> - L<PostgreSQL|http://postgresql.org/>

=item * C<mysql> - L<MySQL|http://mysql.com/>

=item * C<sqlite> - L<SQLite|http://sqlite.org/>

=back

=item C<--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.

=item C<-d>

=item C<--db-name>

  sqitch --db-name widgets
  sqitch -d bricolage

Name of the database. For some engines, such as
L<PostgreSQL|http://postgresql.org/> and L<MySQL|http://mysql.com/>, the
database must already exist. For others, such as L<SQLite|http://sqlite.org/>,
the database will be automatically created on first connect.

=item C<-u>

=item C<--user>

=item C<--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.

=item C<--host>

  sqitch --host db.example.com

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

=item C<--port>

  sqitch --port 7654

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

=item C<--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
(C<core.uri>).

=item C<--top-dir>

  sqitch --top-dir migrations/

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

=item C<--deploy-dir>

  sqitch --deploy-dir db/up

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

=item C<--revert-dir>

  sqitch --revert-dir db/up

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

=item C<--test-dir>

  sqitch --test-dir db/t

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

=item C<--extension>

  sqitch --extension ddl

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

=item C<--etc-path>

  sqitch --etc-path

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

=item C<--quiet>

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

=item C<--verbose>

  sqitch --verbose --verbose

A value between 0 and 3 specifying how verbose Sqitch should be. Unless
C<--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 C<--quiet> is specified.

=item C<--help>

  sqitch --help

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

=item C<--man>

  sqitch --man

Outputs this documentation and exits.

=item C<-V>

=item C<--version>

  sqitch --version

Outputs the program name and version and exits.

=back

=head1 Sqitch Commands

=over

=item L<C<init>|sqitch-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.

=item L<C<status>|sqitch-status>

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.

=item C<log>

*Not yet implemented.

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

=over

=item C<-t>

=item C<-s>

=item C<--change>

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

=item C<-n>

=item C<--max-count>

Limit the number of changes to show.

=item C<--skip>

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

=item C<--since>

Show changes more recent than a specific date.

=item C<--until>

Show changes older than a specific date.

=item C<--user>

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

=item C<--reverse>

Output the changes in reverse sort order.

=item C<--format>

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

=over

=item C<short>

=item C<oneline>

=item C<full>

=item C<table>

=back

=back

=item C<check>

*Not yet implemented.

Sanity check the deployment scripts. Checks include:

=over

=item *

Make sure all deploy scripts have complementary revert scripts.

=back

=item L<C<add>|sqitch-add>

Add a new change.

=item L<C<tag>|sqitch-tag>

List tags or tag the latest change.

=item L<C<rework>|sqitch-rework>

Rework an existing change.

=item L<C<deploy>|sqitch-deploy>

Deploy changes.

=item L<C<revert>|sqitch-revert>

Revert changes.

=item C<test>

*Not yet implemented.

Test changes. All SQL scripts in C<--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.]

=item L<C<config>|sqitch-config>

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

=item C<bundle>

*Not yet implemented.

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

=over

=item C<--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. Property name: C<bundle.from>.

=item C<--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: C<bundle.to>.

=item C<--destdir>

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

=back

=item L<C<help>|sqitch-help>

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

=back

=head1 Configuration

Sqitch configuration can be set up on a project, user, or system-wide basis.
The format of the configuration file, named F<sqitch.conf>, is the same as for
L<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 F<ddl> under the C<migrations> directory. It also wants
bundle to be created in the F<_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 F<~/.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 L<sqitch-config> for a list.

=head1 See Also

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

=over

=item *

L<Simple SQL Change Management|http://justatheory.com/computers/databases/simple-sql-change-management.html>

=item *

L<VCS-Enabled SQL Change Management|http://justatheory.com/computers/databases/vcs-sql-change-management.html>

=item *

L<SQL Change Management Sans Duplication|http://justatheory.com/computers/databases/sql-change-management-sans-redundancy.html>

=back

Other tools that do database change management include:

=over

=item L<Rails migrations|http://guides.rubyonrails.org/migrations.html>

Numbered migrations for L<Ruby on Rails|http://rubyonrails.org/>.

=item L<Module::Build::DB>

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

=item L<DBIx::Migration>

Numbered migrations in pure SQL.

=item L<Versioning|http://www.depesz.com/2010/08/22/versioning/>

PostgreSQL-specific dependency-tracking solution by
L<depesz|http://www.depesz.com/>.

=back

=head1 Author

David E. Wheeler <david@justatheory.com>

=head1 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.

=cut
