On 04/01/2007 03:28 PM, Anoop kumar V wrote:
Sql create statements need to be run using a compatible client.
sqlplus for
oracle, mysqlclient for mysql etc.. Here you just have a target as
part of
your routine build that also takes care of building / renewing your
database
with (or w/o) data.
Sql create statements need to be run using a compatible client. sqlplus for
oracle, mysqlclient for mysql etc.. Here you just have a target as part of
your routine build that also takes care of building / renewing your database
with (or w/o) data.
Plus a layer of abstraction such as a ant for eve
Sounds like perhaps an unnecessary complication, why would this be
better than the root SQL CREATE statements?
-Micah
On 04/01/2007 12:41 PM, Anoop kumar V wrote:
DDLUTILS is what you need:
check this out:
http://db.apache.org/ddlutils/
and better still (if you are using Ant as a build tool)
DDLUTILS is what you need:
check this out:
http://db.apache.org/ddlutils/
and better still (if you are using Ant as a build tool):
http://db.apache.org/ddlutils/ant/
Then you can store these ant scripts in your VCS (version control system).
To create or destroy the schema with data just run an
Using ALTER statements would make it tough to get a complete view. I
would stick with your original idea. This would enable diffs to work
nicely, and the latest revision would contain everything you need to
know to create the database.
-Micah
On 04/01/2007 07:11 AM, Miles Thompson wrote:
Mic
Michael,
We're about to head down the same road, using Subversion, and my thought was to
initially capture a series of CREATE TABLE statements and store them all in
one file.
Then as schema was modified on the development server, update those
statements using SVN.
Your idea looks a lot bett
We keep all of the schema (one file per table) in SVN (subversion)
with a directory to represent each database. As the schema evolves,
we have had no trouble tracking changes through resource history and
are able to extract diffs on every commited change. It works like a
charm and would proably
