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):
> 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 ant target and you
> would be done.
>
> Anoop
>
>
> On 4/1/07, Micah Stevens <micah@raincross-tech.com> wrote:
>>
>> 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:
>> > 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 better, may I presume to outline how I think you
>> > use it?
>> > I'm assuming you capture, for each table, an initial CREATE TABLE,
>> > and save it in a file. Then as the schema changes you update the file
>> > with the ALTER TABLE statements, commiting the changes.
>> >
>> > If you have to recreate the database, you execute the file up to the
>> > last change point.
>> >
>> > I suppose you could do the same thing to maintain the data stored in
>> > lookup tables.
>> >
>> > We're using Joomla! and have extended it quite a bit, and are now
>> > running three databases - dev, beta and since last week, live.
>> >
>> > Later this week I'll be moving myself and one other developer to an
>> > SVN environment; we will see how it goes.
>> >
>> >
>> > Cheers - Miles Thompson
>> >
>> >
>> > At 07:04 PM 3/30/2007, Michael Dykman wrote:
>> >
>> >> 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 work equally as well with CVS.
>> >>
>> >> - michael
>> >>
>> >>
>> >> On 3/30/07, Tim Gustafson <tim@santacruzcomputers.com> wrote:
>> >>> Hello!
>> >>>
>> >>> I'm just getting in to using CVS to track changes to my source code
>> >>> for PHP
>> >>> projects that I'm working on, and it's exactly what my organization
>> >>> needed.
>> >>>
>> >>> However, there does not appear to be a way to track changes to mySQL
>> >>> databases in the same way. Basically, as the structure of tables
>> are
>> >>> changed to meet the requirements of new features, I'd like a way to
>> >>> be able
>> >>> to record those changes (both structural table changes and also
>> >>> "default
>> >>> table data" such as table of states or zip codes or whatever) in a
>> >>> CVS-type
>> >>> system (preferably integrated with CVS directly) so that when a
>> >>> customer
>> >>> uses CVS to get the newest version of the code for their project,
>> >>> they can
>> >>> also get (and automatically apply) all changes to their database for
>> >>> the new
>> >>> version.
>> >>>
>> >>> Does such a system exist? How do other people cope with these types
>> of
>> >>> updates?
>> >>>
>> >>> Thanks for any guidance!
>> >>>
>> >>> Tim Gustafson
>> >>> (831) 425-4522 x 100
>> >>> (831) 621-6299 Fax
>> >>>
>> >>>
>> >>> --
>> >>> MySQL General Mailing List
>> >>> For list archives: http://lists.mysql.com/mysql
>> >>> To unsubscribe:
>> http://lists.mysql.com/mysql?unsub=mdykman@gmail.com
>> >>>
>> >>
>> >>
>> >> --
>> >> - michael dykman
>> >> - mdykman@gmail.com
>> >
>> >
>>
>> --
>> MySQL General Mailing List
>> For list archives: http://lists.mysql.com/mysql
>> To unsubscribe:
>> http://lists.mysql.com/mysql?unsub=a...marv@gmail.com
>>
>>
>
>