> -----Ursprungligt meddelande----- > Från: pgsql-general-owner@xxxxxxxxxxxxxx [mailto:pgsql-general- > owner@xxxxxxxxxxxxxx] För Ralf Schuchardt > Skickat: den 1 juni 2012 18:24 > Till: pgsql-general > Ämne: Re: Question: How do you manage version control? I was using a very simplistic approach a while back. I kept the DDL to create current version from scratch in one file, the DDL to upgrade from last schema version in another and then a small shell script to run the upgrade. I kept the version number in a table for the shell script to check and abort if schema version didn't match and then update after successful upgrade. All files were kept under version control and if I needed older versions of the upgrade file I just browsed the history and got it from there. Very simple, no special tools and easy to run and understand for all developers (even for the "I won't go near sql"-ones). Working with branches makes it a bit harder since the database patch has to be manually handled when merging. Regards, roppert > > Hello, > > am 01.06.2012 um 17:28 schrieb Bryan Montgomery: > > > So we've been reviewing our processes and working on improving them. > One area we've been lacking is a procedure to version control our database > functions, table changes, static data etc. > > we use a very basic system since a few years, consisting mainly of shell scripts > and sql scripts processed by psql. > > > I'm curious how others do it. Ideally, we want it to be part of our release / > build process so that we deploy functions. > > > > However, how do you handle dependancies? > > The code for every recreatable object (i.e. views, functions, maybe types) is > stored in its own file. It includes also a drop statement for these objects and > formal comments to declare dependencies between the files. The files are > processed with a small script that extracts the dependency declarations and > writes a create and drop script for all objects while maintaining the correct > order. > > > We've also used patch files if we need to modify tables - these are typically > written to only run once, ie alter table add column x int. Any thoughts on > putting this in to a process so that it can be run mutliple times without any > issue? > > Our database has a "versions" table, containing the version (and date) of > applied patch files. Every patch file checks the current version in the > database and throws an exception, when it does not match its expected > version. > The directory with the recreatable objects is versioned along the patch files. > > > Regards > Ralf > -- > Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make > changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-general -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
