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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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/[EMAIL PROTECTED]
>>>
>>
>>
>> --
>> - michael dykman
>> - [EMAIL PROTECTED]
>
>
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:
http://lists.mysql.com/[EMAIL PROTECTED]
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
