Forum: Ruby on Rails Migration won't rollback to specific version?

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
59ea1b450935b9d70abfec4186b7a4d5?d=identicon&s=25 Jeff Coleman (progressions)
on 2006-04-05 20:41
Hi all,

I'm confused about how migrations work.  I've been using them for a
couple of weeks but haven't had any serious rollback issues yet.  Just
now I added a field to a table with a migration and ran "rake migrate",
which added the field as expected.

This was in the file db/migrate/007_mymigration.rb, making it version 7.

Later I changed my mind and decided to rollback to the previous schema,
so what I entered was

rake migrate VERSION=006

...which proceeded to drop all the tables in my database.

Now what I'd like to happen is (a) to understand why that happened, and
(b) to be able to run "rake migrate" and have it consecutively run each
migration 001 through 006 in turn and update the database.

I've tried running "rake migrate" again, thinking it would bring
everything up to date, but it seems the only migration it ran was 007,
which failed because the relevant table doesn't exist.

I even deleted the schema_info table, thinking that Rails would
re-create and start at migration 001, but it behaved the same way.

What am I missing?  Is this the correct behavior and I'm doing something
wrong?  Fortunately this was on my development database where all I lost
was some test data.

Thanks,
Jeff
8716cce9a7b721786e5425b8cc1f9951?d=identicon&s=25 sean lynch (Guest)
on 2006-04-05 22:27
You may have to adjust the level of your version in the schema_info
table.

go to the mysql prompt or phpmyadmin, and check what the value is:

your_app> mysql -u root your_dbname_development
...
mysql> explain schema_info;

you will see there is one row one column called version.

then see what the version value is:

mysql> select * from schema_info;

+---------+
| version |
+---------+
|       7 |
+---------+

It will show you what your version number is really set to.
Set it to 0 and run Rake Migrate.

mysql> update schema_info set version = 0 where 1;

you can set the version to any number using this, but your tables must
be in sync with that number.

You can drop all of your other tables if you want to start from scratch.

This will not preserve any data you have in your tables.

-Sean





Jeff Coleman wrote:
>
> Hi all,
>
> I'm confused about how migrations work.  I've been using them for a
> couple of weeks but haven't had any serious rollback issues yet.  Just
> now I added a field to a table with a migration and ran "rake migrate",
> which added the field as expected.
>
> This was in the file db/migrate/007_mymigration.rb, making it version 7.
>
> Later I changed my mind and decided to rollback to the previous schema,
> so what I entered was
>
> rake migrate VERSION=006
>
> ...which proceeded to drop all the tables in my database.
>
> Now what I'd like to happen is (a) to understand why that happened, and
> (b) to be able to run "rake migrate" and have it consecutively run each
> migration 001 through 006 in turn and update the database.
>
> I've tried running "rake migrate" again, thinking it would bring
> everything up to date, but it seems the only migration it ran was 007,
> which failed because the relevant table doesn't exist.
>
> I even deleted the schema_info table, thinking that Rails would
> re-create and start at migration 001, but it behaved the same way.
>
> What am I missing?  Is this the correct behavior and I'm doing something
> wrong?  Fortunately this was on my development database where all I lost
> was some test data.
>
> Thanks,
> Jeff
59ea1b450935b9d70abfec4186b7a4d5?d=identicon&s=25 Jeff Coleman (progressions)
on 2006-04-05 22:30
sean lynch wrote:

> You can drop all of your other tables if you want to start from scratch.
>
> This will not preserve any data you have in your tables.
>
> -Sean

I actually did this, I even completely dropped all the tables from my
schema, including the schema_info table.

Still it only attempts to run the most recent migration, which fails
because those tables don't exist.

Are there any other factors influencing this?

Jeff
59ea1b450935b9d70abfec4186b7a4d5?d=identicon&s=25 Jeff Coleman (progressions)
on 2006-04-05 23:11
Jeff Coleman wrote:
> sean lynch wrote:
>
>> You can drop all of your other tables if you want to start from scratch.
>>
>> This will not preserve any data you have in your tables.
>>
>> -Sean
>
> I actually did this, I even completely dropped all the tables from my
> schema, including the schema_info table.
>
> Still it only attempts to run the most recent migration, which fails
> because those tables don't exist.
>
> Are there any other factors influencing this?
>
> Jeff

I just tried creating a brand new rails app and a fresh database schema,
to test this out.

I ran "rails funky" to create a new app called "funky", edited my
database.yml to associate it to a schema called "funk_development", and
ran "ruby script/generate migration item".

Then I created the follow two simple migration files in db/migrate:

001_item.rb:

class Item < ActiveRecord::Migration
  def self.up
		create_table :item do |table|
			table.column :name, :string
			table.column :price, :integer, :limit => 4
		end
  end

  def self.down
		drop_table :item
  end
end

002_item.rb

class Item  < ActiveRecord::Migration
  def self.up
		add_column :item, :description, :text
  end

  def self.down
		remove_column :item, :description
  end
end

According to all the documentation I've seen, running this on an empty
database should first run 001_item.rb and then 002_item.rb, creating and
updating the schema_info table with the current version number (2).

This is what happened:

C:\rails\funky>rake migrate
(in C:/rails/funky)
== Item: migrating
============================================================
-- add_column(:item, :description, :text)
rake aborted!
Mysql::Error: #42S02Table 'funky_development.item' doesn't exist: ALTER
TABLE it
em ADD description text

(See full trace by running task with --trace)

Again it ran only the most recent migration, ignoring the first.  The
"schema_info" table was created but when the migration failed its
version remained set at 0.

Anyone have any ideas?  I have not been able to get migration on
multiple migration files to perform as described with even the most
simple trivial examples.

Am I misunderstanding how it should work?  What's going on here?

Thanks again,
Jeff Coleman
59ea1b450935b9d70abfec4186b7a4d5?d=identicon&s=25 Jeff Coleman (progressions)
on 2006-04-05 23:14
Jeff Coleman wrote:
> Anyone have any ideas?  I have not been able to get migration on
> multiple migration files to perform as described with even the most
> simple trivial examples.
>
> Am I misunderstanding how it should work?  What's going on here?

Just a further note--I mistyped the schema name in my previous message,
"funky_development", rather than "funk_development".

Also, I'm using MySQL 5.0 on Windows XP, with Rails 1.1, Ruby 1.8.2, and
Rake 0.7.0.

Thanks,
Jeff Coleman
8716cce9a7b721786e5425b8cc1f9951?d=identicon&s=25 sean lynch (Guest)
on 2006-04-05 23:44
Each migration should have a unique name or you get a class name
conflict.

In your case Migrate has created two classes with the same name 'Item':
> class Item < ActiveRecord::Migration
...
> end

try it with itema and itemb.

Are all of your migration classes named the same?

This could be causing errors.
3dd4b52a0946bd698b1d1635a46ea3a3?d=identicon&s=25 François Beausoleil (fbeausoleil)
on 2006-04-05 23:46
(Received via mailing list)
Hello Jeff,

2006/4/5, Jeff Coleman <progressions@gmail.com>:
> 001_item.rb:
> class Item < ActiveRecord::Migration
> end
>
> 002_item.rb
> class Item  < ActiveRecord::Migration
> end

You must have different names for each migration.  The second
migration overwrote the first one, which means the table didn't get
created as your migration expected.

For you original problem, I think the problem might have been related
to the fact you typed version as "006" instead of plain "6".

Try that and see how it goes.

Bye !
59ea1b450935b9d70abfec4186b7a4d5?d=identicon&s=25 Jeff Coleman (progressions)
on 2006-04-05 23:47
sean lynch wrote:
> Each migration should have a unique name or you get a class name
> conflict.
>
> In your case Migrate has created two classes with the same name 'Item':
>> class Item < ActiveRecord::Migration
> ...
>> end
>
> try it with itema and itemb.
>
> Are all of your migration classes named the same?
>
> This could be causing errors.

So far I've only used one migration per application.  I tried that
example first with migrations called "001_funky.rb"/"002_funky.rb" and
then changed their names to "item" instead of "funky".

Are you saying there should be a different migration for each table?

Jeff
59ea1b450935b9d70abfec4186b7a4d5?d=identicon&s=25 Jeff Coleman (progressions)
on 2006-04-05 23:48
François Beausoleil wrote:
> Hello Jeff,
>
> 2006/4/5, Jeff Coleman <progressions@gmail.com>:
>> 001_item.rb:
>> class Item < ActiveRecord::Migration
>> end
>>
>> 002_item.rb
>> class Item  < ActiveRecord::Migration
>> end
>
> You must have different names for each migration.  The second
> migration overwrote the first one, which means the table didn't get
> created as your migration expected.
>
> For you original problem, I think the problem might have been related
> to the fact you typed version as "006" instead of plain "6".
>
> Try that and see how it goes.
>
> Bye !

Oh, I should name the migration something like:

001_item_tables.rb
002_item_names.rb
003_item_prices.rb

Like so?

I figured the number itself would control the versioning and the rest of
the filename should be the same.

Jeff
59ea1b450935b9d70abfec4186b7a4d5?d=identicon&s=25 Jeff Coleman (progressions)
on 2006-04-06 00:13
Thans, guys.  I hadn't realized migrations should each be named
differently.  I have to admit I don't understand why that is.  I was
assuming I could just create a sequence of migrations tied to my
application--for example, 001_blog.rb to 002_blog.rb for an app called
"blog".

But at least now I understand how it does work.  Thanks!
Jeff
8716cce9a7b721786e5425b8cc1f9951?d=identicon&s=25 sean lynch (Guest)
on 2006-04-06 00:38
You can have multiple tables in a migration, but the migrations must
have unique names, because the class created in the migration is based
on the name you give.

The 001 or 002 from the file name is not included in the class name.

Here is an example that creates a new table and adds a column to an
existing table:

class Addtable2 < ActiveRecord::Migration

  def self.up
    create_table :new_table do |table|
      table.column :name, :string
      table.column :address, :text
      table.column :pay_type, :string
    end
    add_column :old_table, :new_table_id, :integer
  end

  def self.down
    remove_column :old_table, :new_table_id_id
    drop_table :orders
  end
end

The create table and the add column is at the same level. I could have
multiple create tables.

The new column in the old_table will hold the id from the new_table, so
I remove the column before dropping the table in my self.down

------------------------------------------------------------------------

-sean
Jeff Coleman wrote:
> Thans, guys.  I hadn't realized migrations should each be named
> differently.  I have to admit I don't understand why that is.  I was
> assuming I could just create a sequence of migrations tied to my
> application--for example, 001_blog.rb to 002_blog.rb for an app called
> "blog".
>
> But at least now I understand how it does work.  Thanks!
> Jeff
8716cce9a7b721786e5425b8cc1f9951?d=identicon&s=25 sean lynch (Guest)
on 2006-04-06 00:40
that should be

      drop_table :new_table

I forgot to overwrite the code to my example names

>   def self.down
>     remove_column :old_table, :new_table_id_id
>     drop_table :orders         <----error here
>   end
8716cce9a7b721786e5425b8cc1f9951?d=identicon&s=25 sean lynch (Guest)
on 2006-04-06 00:40
that should be

      remove_column :old_table, :new_table_id
      drop_table :new_table

I forgot to overwrite the code to my example names

>   def self.down
>     remove_column :old_table, :new_table_id  <----error here
>     drop_table :orders                       <----error here
>   end
8716cce9a7b721786e5425b8cc1f9951?d=identicon&s=25 sean lynch (Guest)
on 2006-04-06 00:45
Look in the files created by your migrations with the same names. You
will see a class named after the name you give. having multiple classes
with the same name causes namespace collisions.

Just like in most other OO languages.

There is always that one joker on any java project who has to redefine
the '+' operator to do subtraction. You know.


-Sean


Jeff Coleman wrote:
> Thans, guys.  I hadn't realized migrations should each be named
> differently.  I have to admit I don't understand why that is.  I was
> assuming I could just create a sequence of migrations tied to my
> application--for example, 001_blog.rb to 002_blog.rb for an app called
> "blog".
>
> But at least now I understand how it does work.  Thanks!
> Jeff
59ea1b450935b9d70abfec4186b7a4d5?d=identicon&s=25 Jeff Coleman (progressions)
on 2006-04-06 00:47
Thanks, Sean.

I guess it just seemed natural to me that there'd be a global
application-level series of migrations, that would run in sequence.
It's cleared up now, though.  Thanks!

Jeff

sean lynch wrote:
> Look in the files created by your migrations with the same names. You
> will see a class named after the name you give. having multiple classes
> with the same name causes namespace collisions.
>
> Just like in most other OO languages.
>
> There is always that one joker on any java project who has to redefine
> the '+' operator to do subtraction. You know.
>
>
> -Sean
>
>
> Jeff Coleman wrote:
>> Thans, guys.  I hadn't realized migrations should each be named
>> differently.  I have to admit I don't understand why that is.  I was
>> assuming I could just create a sequence of migrations tied to my
>> application--for example, 001_blog.rb to 002_blog.rb for an app called
>> "blog".
>>
>> But at least now I understand how it does work.  Thanks!
>> Jeff
9d7d8ef2179661d6b30e180fa588cd45?d=identicon&s=25 Calle Dybedahl (Guest)
on 2006-04-06 08:44
(Received via mailing list)
>>>>> "sean" == sean lynch <sean.seanlynch@gmail.com> writes:

> You can have multiple tables in a migration, but the migrations must
> have unique names, because the class created in the migration is based
> on the name you give.

> The 001 or 002 from the file name is not included in the class name.

Perhaps it should be, just to prevent this kind of confusion. It's not
the first time someone's posted about exactly this problem on this
list, and the current behaviour is somewhat counterintuitive.
--
		     Calle Dybedahl <calle@cyberpomo.com>
		 http://www.livejournal.com/users/cdybedahl/
  "You know, if I garbage collected my brain I wouldn't have anything
left."
			   -- Paul Tomblin, BofhNet
59ea1b450935b9d70abfec4186b7a4d5?d=identicon&s=25 Jeff Coleman (progressions)
on 2006-04-06 08:50
Calle Dybedahl wrote:
>>>>>> "sean" == sean lynch <sean.seanlynch@gmail.com> writes:
>
>> You can have multiple tables in a migration, but the migrations must
>> have unique names, because the class created in the migration is based
>> on the name you give.
>
>> The 001 or 002 from the file name is not included in the class name.
>
> Perhaps it should be, just to prevent this kind of confusion. It's not
> the first time someone's posted about exactly this problem on this
> list, and the current behaviour is somewhat counterintuitive.
> --
> 		     Calle Dybedahl <calle@cyberpomo.com>

Frankly I don't quite understand why the behavior I thought was
intuitive doesn't work?  It seemed very natural to me to think that,
since the files are numbered in sequence, the text part of the filename
and class should be the same.

I see now that, I guess because of how it's implemented, they're classes
which have to be named differently so they don't clash, but to have an
app called "blog" and a series of migrations called "001_blog",
"002_blog", "003_blog" seemed natural and intuitive to me.

Jeff Coleman
This topic is locked and can not be replied to.