Skit is a tool for managing database development. Its purpose is to allow the database definition to be managed using a Source Code Management system, and to provide the means to upgrade and patch databases in a similar way to that done for source code. It is being primarily developed for PostgreSQL but could esaily be extended to deal with other databases.
The name, skit, is a contraction of the term Schema Tools.
Skit has the following built-in capabilities:
The extract command connects to a database and generates an xml representation of the database schema.
Generates ddl code for building or dropping the objects in an xml schema definition as created by extract or diff.
Compares two xml schema definitions, yielding a diff schema. The diff schema can be fed to the generate command to create ddl to patch a database from one version to another.
Filters the objects in an xml schema definition. This allows partial schemas to be generated/dropper/patched without having to edit the ddl scripts created by generate.
Displays a list of database objects within an xml schema or diff file, showing which, if any, have been filtered out by grep.
Takes an xml schema and creates a directory tree containing one file per database object. This directory tree is the thing which should be managed by an SCM.
The logical inverse of scatter.
Skit may run many commands in a single session. Each command places its result(s) on an internal stack from which the next command will retrieve it. If the last command does not specify printing, and there is any document on the stack, the topmost document will be automatically printed.
Examples of skit commands:
skit –extract –connect “-h localhost -p 5435” --print
skit –extact
skit –extract –list
skit –extract –gather gatherrootdir –diff –list
skit –diff file1 file2
skit –gather gatherrootdir –list
skit –diff –swap file1 file2 –grep schema.x –generate
The first skit release is targetted for early 2009 and will be for postgres 8.1. Updates are expected to quickly follow for postgres 8.2 and 8.3. I am unlikely to write handlers for other databases but it could fairly easily be done.
More to follow, including architectural overviews, developer guidelines, etc.
Email the author, Marc Munro.