Russ,
On Jun 10, 2005, at 2:34 PM, Russ Brown wrote:
This certainly is a far more complex problem than I originally thought
it was. I'd like any solution to be able to work in any version
control system, and to be applicable to any database engine (my
employer is a MySQL house, while I personally prefer Postgres for my
personal stuff, so I'm in favour of it being completely portable).
Another important design criteria for me would be ease of use. This is
a version-control stage on top of the existing version control work
that a developer needs to do, and if it's a real hassle they aren't
going to bother to do it properly. It therefore needs to be able to do
things as automatically as possible, for example by connecting to a
database and generating the manifest file directly.
I think what this amounts to is basically doing the task as it has
traditionally been accomplished (and already suggested in the thread).
There is a baseline schema and any group of developers needs to share a
version controlled file to transform the schema into a new version.
This could involve schema and data modifications.
As you say, unless there is a huge win for developers no one will take
the time to learn some other specification method (i.e. some type of
XML manifest). I think the best approach is a tool that takes the
baseline schema, new schema, and current transform script and then
generates the SQL needed for the next revision. The developer would
simply need to review the generated code, adjust it (if necessary), and
then commit it as the next revision.
John DeSoi, Ph.D.
http://pgedit.com/
Power Tools for PostgreSQL
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
