Problem using "rake db:migrate"

Hi all,

I am facing a problem while using rails “migrate” feature for creating
tables in a database.

Following are the details.

I have 2 applications say “app1” & “app2”. I want both of them to use
same
database say “testdb”.

For “app1”, I create 3 models which in turn create 3 migration files
with
prefix, 001_, 002_ & 003_. Now I execute “rake db:migrate” so that 3
tables
corresponding to 3 models will get created in database “testdb” &
schema_info table will have version = 3.

So far, so good.

Now, from “app2” I want to create a new table, for which I create a new
model, which creates a migration file with prefix “001_”(as this is
version
1 for app2). In this file, I write a code to create a table say
“table1”
for the new model, execute command “rake db:migrate” & here comes the
problem.
As currently, database “testdb” has version “3”, & the migration file
for
“app2” has a prefix “001_” , rake migrate command will think that the
migrations are already applied & will not execute the method “self.up”
in
“001_…” file of “app2” & the table “table1” which I want to get
created,
will not get created.

One possible workaround to this problem could be as follows:

  1. After creating a model for “app2”, read current database version
    in
    schema_info table of “testdb” say cur_db_version.
    2. In “app2”, rename file prefix from “001_” to
    “00<cur_db_version+1>" (in this case "004”) & then run “rake
    db:migrate”
    command for “app2”.

This is not 100% correct solution, as it may introduce other problems as
I
move ahead. E.g. in “app1”, I want to delete the third table(created by
migration file “003_”), so I will run command “rake db:migrate
VERSION=2” so
that the down method of “003_” file of “app1” will be executed to drop
this
table & database will be at version 2.

Now, in “app2” I execute command “rake db:migrate” , which will run
self.upof “004_” file in “app2”, which has the code to create table
“table1”, which
is already present in database. & thus “rake db:migrate” will fail.
There
can be many such problems with this approach.

Have anybody faced similar problem & has better solution for it?

This migrate feature seems to be based on the assumption that each
application uses a separate database. (as the schema_info table has only
1
column & a row.) Is this the case? Any thoughts on this?

        Any inputs on this will be greatly appreciated.

With Best Regards,
Medha.

—If not you then who…
If not now then when…

You could share the db/ directory with your
version control system, much as many people
share the app/models/ directory between
applications.


– Tom M.