Rails - Jun 2006 - 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......
-----------------------------------------------------
With Best Regards,
Medha.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060618/707af9f8/attachment.html

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

--  
-- Tom Mornini

On Jun 18, 2006, at 5:00 AM, Medha Kulkarni wrote:
> 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:
> After creating a model for "app2", read current database version
in
> schema_info table of "testdb" say cur_db_version.
> 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.up of "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......
> -----------------------------------------------------
> With Best Regards,
> Medha.
>
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails