Re: what database schema version management system to use?

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: Alexey Bashtanov <bashtanov(at)imap(dot)cc>
Cc: PostgreSQL General <pgsql-general(at)postgresql(dot)org>
Subject: Re: what database schema version management system to use?
Date: 2016-04-08 14:09:22
Message-ID: CAHyXU0yYGmtwg8KQuyZ_9BpxQ+DqDksomh6OpiycH7yge4LF1w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Wed, Apr 6, 2016 at 5:55 AM, Alexey Bashtanov <bashtanov(at)imap(dot)cc> wrote:
> Hi all,
>
> I am searching for a proper database schema version management system.
>
> My criteria are the following:
> 0) Open-source, supports postgresql
> 1) Uses psql to execute changesets (to have no problems with COPY,
> transaction management or sophisticated DDL commands, and to benefit from
> scripting)
> 2) Support repeatable migrations (SQL files that get applied every time
they
> are changed, it is useful for functions or views tracking).
>
> Reasonable?
>
> But unfortunately it looks like each of Liquibase, Flyway, SqlHawk,
> MigrateDB, Schema-evolution-manager, Depesz's Versioning, Alembic and
Sqitch
> does not satisfy some of those, right?
>
> What DB VCS do you use and how does it related with the criteria listed
> above?
> Do you have any idea what other systems to try?

I rolled my own in bash. It wasn't that difficult. The basic tactic is to:

*) separate .sql that can be re-applied (views, functions, scratch tables,
etc) from .sql that can't be re-applied (create table, index, deployment
data changes etc). I call the former 'soft' and latter 'hard' changes.
*) keep each database tracked in its own folder in the tree and put all the
soft stuff there. I keep all the hard stuff in a folder, 'schema'. I also
ha ve a special library folder which tracks all databases
*) redeploy 'soft' changes every release. The bash script deploys files in
mtime order after setting mtime to git commit time since git doesn't track
mtime
*) keep a tracking table in each database tracking deployed scripts

Here is example of output:
mmoncure(at)mernix2 09:07 AM (AO_3_9) ~/src/aodb/release/ao$ DRY_RUN=1
./deploy.sh

-----------DEPLOYMENT STARTING--------------

LOG: Dry run requested
LOG: Attempting connection to control database @ host=
rcoylsdbpgr001.realpage.com dbname=ysconfig port=5432
LOG: Got connection host=10.34.232.70 dbname=ysconfig port=5432 to ysconfig
LOG: Got connection host=10.34.232.70 dbname=ysanalysis port=5432 to
ysanalysis
LOG: Got connection host=10.34.232.70 dbname=revenueforecaster port=5432 to
revenue forecaster
LOG: Got connection host=10.34.232.68 dbname=cds2 to node
LOG: Release folder is /home/mmoncure/src/aodb/release/ao/SAT/1.0.0
LOG: Database host=10.34.232.70 dbname=ysconfig port=5432 is getting update
PropertyNicheSchema.sql
LOG: Database host=10.34.232.70 dbname=ysanalysis port=5432 is getting
update PropertyNicheSchema.sql
LOG: Database host=10.34.232.70 dbname=revenueforecaster port=5432 is
getting update PropertyNicheSchema.sql
LOG: Database host=10.34.232.68 dbname=cds2 is getting update
PropertyNicheSchema.sql
LOG: Database host=10.34.232.70 dbname=ysanalysis port=5432 is getting
update ca_scenario_position.sql
LOG: building SAT ysconfig update script
LOG: building SAT ysanalysis update script
LOG: building SAT revenueforecaster update script
LOG: building SAT node update script
LOG: Applying SAT ysconfig update to host=10.34.232.70 dbname=ysconfig
port=5432
LOG: ysconfig successfully updated!
LOG: Applying SAT ysanalysis update to host=10.34.232.70 dbname=ysanalysis
port=5432
LOG: ysanalysis successfully updated!
LOG: Applying SAT revenue forecaster update to host=10.34.232.70
dbname=revenueforecaster port=5432
LOG: revenueforecaster successfully updated!
LOG: Applying SAT node id 0 update to host=10.34.232.68 dbname=cds2
LOG: node 0 successfully updated!
LOG: Applying SAT node id 1 update to host=10.34.232.69 dbname=cds2
LOG: node 1 successfully updated!

LOG: Dry run requested: changes not committed!

merlin

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2016-04-08 14:20:27 Re: max_stack_depth problem though query is substantially smaller
Previous Message Marllius 2016-04-08 13:16:24 Re: Postgresql 9.3.4 file system compatibility