Must support keeping creation script in sync with the db schema

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Create a create-schema.sql file with a single table with single column 
name.
2. Create a another migration file and add a new column age to the above 
table.
3.

What is the expected output? What do you see instead?

What version of the product are you using? On what operating system?
0.9.7

Please provide any additional information below.

Over time if i keep doing modifications to the schema with new migration 
files then it is very hard to understand what my current active schema has 
at any point of time. That is i want to keep my create-schema.sql always 
upto date to reflect the db schema.

What i mean is at any time if i look at create-schema.sql it should 
reflect the current db schema. 

Expected functionality should be: Everytime user creates/resets the db 
schema the db-migration script should run only create-schema.sql and 
ignore all migration scripts. Migration scripts should be run only on 
existing schemas to keep them upto date.

This way it give me a flexibility of maintaining the create-schema.sql in 
sync with actual schema. Also at any point of time if you are creating a 
fresh db schema then execute only one file. So, db-migration script should 
accept InitialSchemaFile as argument to achieve this

thanks.

Original issue reported on code.google.com by ragh...@gmail.com on 24 May 2009 at 9:49

[GoogleCodeExporter]

You can produce such a script using the tools that come with your database (e.g.
mysqldump for MySQL).  Having two representations of the schema -- the sum of
migration files plus create-schema.sql -- violates DRY, which in my opinion is a
pretty good reason to not implement this feature.

I agree that over time, as the number of migrations grows, it becomes difficult 
to
looks at the migrations to see your schema and it takes a bit longer to reset 
than
one might like.  Migrations are discrete changes to an schema over time, so 
they're
not intended to provide an overview of the db schema.  Other tools do that way 
better
(toad, db visualizer, etc).  I  periodically roll up migrations by removing all
migrations from version control and creating a new migration from an existing
up-to-date db instance.  It can be a little tricky and takes a few minutes, but 
it's
not too bad.

I'm going to close this as a "Won't Fix" since it's not a feature I plan on 
folding
in at this time.  Thanks though.

Original comment by christia...@gmail.com on 24 Aug 2009 at 10:20

• Changed state: WontFix

[GoogleCodeExporter]

I think i didn't present the issue properly. This will be a feature which is 
very 
useful during development which involve more than one developer.

Lets take a scenario:

Jan 2008:
Developer-1 and Developer-2 Started working on a project and created their 
project 
and started working.
Developer-1 and Developer-2 kepts theirs development box's DB uptodate with 
migration scripts

April 2009:
Developer-2 is out for a vacation.
Developer-1 created some migration scripts

May 2009:
Developer-3 newly joined the project.

June 2009:
Developer-2 returned from Vacation

- I dont want developer-3 to run all the migration scripts since 2008 to create 
his 
new DB. He must be able to run a single schema creation script.
- I dont want developer-2 to recreate his DB when he comes back from vacation 
because Developer-1 unified/cleaned up migration scripts to help Developer-3 to 
setup his box.

Make Sense?

Original comment by ragh...@gmail.com on 1 Sep 2009 at 7:36