After some consideration, I changed the name of my db manager project to dbMorph. Naming it dbSync was a little misleading as syncing really implies bringing something in sync with something else or syncing to disk, etc., while this tool is really for managing database changes.
Work is starting on 2/4 (Monday) and tomorrow I'm doing a mini presentation on how this tool will work. Here are some excerpts:
Proposal: dbMorph
What is it?
A tool to keep database objects and stored procedures synchronized with application code in a multi-developer environment with a short release cycle and multiple development branches. Tie-in to svn (subversion) for version control.
Why do I need it?
Historically, applying database changes falls onto the shoulders of both system administrators, database administrators and developers. This role is not very well defined and varies widely from project to project. DbMorph allows the roles to be more defined, as follows:
- Developers write the database changes: any DDL changes, DML and updates to stored procedures.
- DbMorph generates a file that can be run on an existing database schema to update it (or downgrade it) to a desired version. DbMorph guarantees that correct versions of stored procedures are applied and that no change is applied out of order or more than necessary
- Admins or developers can now run the generated file on a desired schema. This is most useful in two main scenarios: administrators (sysadmins, dbas) can apply these changes to systems in production during releases and developers can apply these changes to schemas they manage on their own (e.g. in a local dev setup) during development.
How will it be released?
DbMorph will be released under the new BSD License. This means that the name of the author is preserved as the software is used, however, the end user has the freedom to do anything with the software (as long as they preserve the author's name).
I did not choose the GPL license due to its viral nature - it infects any code it is a part of and any code that uses it would have to be then further released. This would not work in a setting such as an agency where you might write software for someone else who wants to own it.
How do you know it will work?
I have already written what could be considered a very technology-specific version of this tool and use it on a daily basis. It works for the specific project I'm using it for, but it does not support a variety of databases nor applications in various programming languages.
Wait, doesn't a tool like this already exist?
There are a few tools that attempt to support similar functionality, but in most cases they miss the idea that stored procedures (e.g. code written in PL/SQL) and application code (e.g. PHP, Java) are both maintained under version control. The feature that differentiates dbMorph from other tools is considering any stored procedures as living and breathing code under svn. It will retrieve the correct versions of those files depending on the database revision within the development process. This especially applies in environments with multiple development branches that release code on a frequent basis.
Ok, gimme the specs!
This tool will be written in Python. Doing so makes the tool OS-blind and portable.
The tool will give users freedom in how database deltas (changes) are stored. The default storage engine will be XML. Adding a new storage engine will simply mean implementing a provided interface.
The tool will attempt to support a variety of databases. The original release will include support for Oracle and MySQL.
The tool depends on svn (subversion) for version control. Svn is a widely-recognized version control that will most likely be around for quite some time (*cross fingers*).
DbMorph can be run from command line.