view release on metacpan or  search on metacpan

lib/sqitch.pod  view on Meta::CPAN

=item * L<Exasol|https://www.exasol.com/> 6.0+

=item * L<Snowflake|https://www.snowflake.net/>

=item * L<ClickHouse|https://www.clickhouse.com/clickhouse/> 24+

=back

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 tied to any framework, ORM, or platform. Rather, it is a
standalone change management system with no opinions about your database
engine, application framework, or development environment.

=item Native scripting

Changes are implemented as scripts native to your selected database engine.
Writing a L<PostgreSQL|https://postgresql.org/> application? Write SQL scripts
for L<C<psql>|https://www.postgresql.org/docs/current/static/app-psql.html>.
Writing an L<Oracle|https://www.oracle.com/us/products/database/>-backed app?
Write SQL scripts for L<SQL*Plus|https://www.orafaq.com/wiki/SQL*Plus>.

=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 -- even on changes
from other Sqitch projects. This ensures proper order of execution, even when
you've committed changes to your VCS out-of-order.

=item Deployment integrity

Sqitch manages changes and dependencies via a plan file, and employs a
L<Merkle tree|https://en.wikipedia.org/wiki/Merkle_tree> pattern similar to
L<Git|https://stackoverflow.com/a/18589734/> and
L<Blockchain|https://medium.com/byzantine-studio/blockchain-fundamentals-what-is-a-merkle-tree-d44c529391d7>
to ensure deployment integrity. 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.


=item Iterative Development

Up until you L<tag|sqitch-tag> and L<release|sqitch-bundle> your project, you
can modify your change deployment scripts as often as you like. They're not
locked in just because they've been committed to your VCS. This allows you to
take an iterative approach to developing your database schema. Or, better, you
can do test-driven database development.

=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|https://en.wikipedia.org/wiki/Idempotence>, you can change
your code directly, and Sqitch will know it needs to be updated.

=end comment

=back

Ready to get started? Here's where:

=over

=item Sqitch Tutorials

Detailed tutorials demonstrating the creation, development, and maintenance
of a database with Sqitch.

=over

=item * L<PostgreSQL, YugabyteDB, CockroachDB Tutorial|sqitchtutorial>

=item * L<SQLite Tutorial|sqitchtutorial-sqlite>

=item * L<MySQL Tutorial|sqitchtutorial-mysql>

=item * L<Oracle Tutorial|sqitchtutorial-oracle>

=item * L<Firebird Tutorial|sqitchtutorial-firebird>

=item * L<Vertica Tutorial|sqitchtutorial-vertica>

=item * L<Exasol Tutorial|sqitchtutorial-exasol>

=item * L<Snowflake Tutorial|sqitchtutorial-snowflake>

=back

=item L<PDX.pm Presentation|https://speakerdeck.com/theory/sane-database-change-management-with-sqitch>

Slides from "Sane Database Management with Sqitch", presented to the Portland
Perl Mongers in January, 2013.

=item L<PDXPUG Presentation|https://vimeo.com/50104469>