Rails - Aug 2006 - rake migrate the first time - uses more than schema_info?

All,

I have two migration files, file 1 and file 2.

For reasons that I don''t want to go into unless I must, I want to only 
run file 2 on my production database (file 1 contains a bunch of table 
creation stuff for already existing tables).

I figured if I created a schema_info table and set the version in it to 
1, then I could just run rake db:migrate RAILS_ENV=production and just 
file 2 would get run.

However, it keeps trying to run file1 and fails because as I said, those 
things already exist.  Basically, it is ignoring or not seeing the 
schema_info version.  I am pretty sure that it should be able to read 
the version from that table.

So, I am led to believe that the first time that you run rake 
db:migrate, it must be looking for something in addition to/instead of 
the version in the schema_info table to figure out that it wants to run 
starting with the first migration file.

Here''s the output of rake --trace db:migrate

[dusan@exmit2 current]$ rake --trace db:migrate RAILS_ENV=production
(in /home/dusan/eSimplyTest/releases/20060808203414)
** Invoke db:migrate (first_time)
** Invoke environment (first_time)
** Execute environment
** Execute db:migrate

Do I have to fiddle with my migration files on my production box?

Any info. on this?

Thanks,
Wes

-- 
Posted via http://www.ruby-forum.com/.

I''ve verified that it is looking only at schema_info.

There must be something wrong with my production DB setup so that 
schema_info can''t be seen.

When rake runs for a given environment, won''t it connect to the
database
as the user specified in database.yml for the environment name specified 
in RAILS_ENV?

Wes

-- 
Posted via http://www.ruby-forum.com/.

My problem is that my production DB user is not connecting correctly and 
is not able to read the schema_info table.

Wes


-- 
Posted via http://www.ruby-forum.com/.

On Tue, 2006-08-08 at 22:44 +0200, Wes Gamble wrote:
> All,
> 
> I have two migration files, file 1 and file 2.
> 
> For reasons that I don''t want to go into unless I must, I want to
only
> run file 2 on my production database (file 1 contains a bunch of table 
> creation stuff for already existing tables).
> 
> I figured if I created a schema_info table and set the version in it to 
> 1, then I could just run rake db:migrate RAILS_ENV=production and just 
> file 2 would get run.
> 
> However, it keeps trying to run file1 and fails because as I said, those 
> things already exist.  Basically, it is ignoring or not seeing the 
> schema_info version.  I am pretty sure that it should be able to read 
> the version from that table.
> 
> So, I am led to believe that the first time that you run rake 
> db:migrate, it must be looking for something in addition to/instead of 
> the version in the schema_info table to figure out that it wants to run 
> starting with the first migration file.
> 
> Here''s the output of rake --trace db:migrate
> 
> [dusan@exmit2 current]$ rake --trace db:migrate RAILS_ENV=production
> (in /home/dusan/eSimplyTest/releases/20060808203414)
> ** Invoke db:migrate (first_time)
> ** Invoke environment (first_time)
> ** Execute environment
> ** Execute db:migrate
> 
> Do I have to fiddle with my migration files on my production box?
> 
> Any info. on this?
----
how about something like...

rake db:schema:dump
put the result into schema.rb
set version value in schema_info table to ''1''

and then do rake db:migrate RAILS_ENV=production --trace

Craig

On Tue, 2006-08-08 at 23:17 +0200, Wes Gamble wrote:
> My problem is that my production DB user is not connecting correctly and 
> is not able to read the schema_info table.
----
one of us can fix that and it isn''t me

Craig

It''s fixed.  Thanks for responding.

-- 
Posted via http://www.ruby-forum.com/.

On Tue, 2006-08-08 at 22:47 +0200, Wes Gamble wrote:
> I''ve verified that it is looking only at schema_info.
> 
> There must be something wrong with my production DB setup so that 
> schema_info can''t be seen.
> 
> When rake runs for a given environment, won''t it connect to the
database
> as the user specified in database.yml for the environment name specified 
> in RAILS_ENV?
----
try connecting to the database as that user from the command line client

Craig