"No such column" when renaming some columns in the migrations

[jacob-carlborg]

I'm updating our Rails application from 2.3 to 3.2.8. We have some problem running the migrations. For some of the renames in the migrations we get an error message: "No such column". I've debugged the issue and it seems there's some kind of problem with the schema cache. If I add a debugger just before the following exception is raised:

https://github.com/rails-sqlserver/activerecord-sqlserver-adapter/blob/master/lib/active_record/connection_adapters/sqlserver/schema_statements.rb#L282

If I then, in the debugger, run schema_cache.columns[table_name].length I get back 5. But when I run columns(table_name).length I get back 24. When I call columns I can see in the returned value that it do contains the column we want to rename. So it seems the schema cache isn't updated correctly, for some reason.

I don't know if it matters but we have migrations both with the old style, just an incremented number in the name of the migration. And the current style with a date and a number.

[jacob-carlborg]

Forgot to mention, if I run the migration the first time it will raise an exception. But the second time it will work, because, I assume, the schema remains in the database.

You are not likely using ActiveRecord's #reset_column_information during your migration in the right place.

http://api.rubyonrails.org/classes/ActiveRecord/Migration.html

• Ken

On Oct 26, 2012, at 5:22 AM, jacob-carlborg notifications@github.com wrote:

Forgot to mention, if I run the migration the first time it will raise an exception. But the second time it will work, because, I assume, the schema remains in the database.

—
Reply to this email directly or view it on GitHub.

[jacob-carlborg]

I'm not sure but reset_column_information seems to be related to using models or populating a new column from the migration. We're not using any models or adding data from the migrations. Here is a migration that fails:

class RenameNewToIsNewInItem < ActiveRecord::Migration
  def self.up
    rename_column :items, :new_item, :is_new
  end

  def self.down
    rename_column :items, :is_new, :new_item
  end
end

[metaskills]

I thought migrations in 3.2 were up/down instance methods, not class methods?

[jacob-carlborg]

These are old ones.

[jrafanie]

Do you have any migrations prior to this one that when run(in one db:migrate call), loads the Item class or a stub of the Item class? If I recall, once the class is loaded into memory, the column info is cached, so you need to follow Ken's advice and use Item.reset_column_information after changing the columns or don't use the Item class/stub in prior migrations.

[Fryguy]

I addition to Joe's comment. This seems to be a difference from prior
versions of ActiveRecord where model caches were stored in the model
itself. Now, they seem to be stored at a higher common level.

On Fri, Oct 26, 2012 at 10:56 AM, Joe Rafaniello
notifications@github.comwrote:

Do you have any migrations prior to this one that when run(in one
db:migrate call), loads the Item class or a stub of the Item class? If I
recall, once the class is loaded into memory, the column info is cached, so
you need to follow Ken's advice and Item.reset_column_information after
changing the columns or don't use the Item class/stub in prior migrations.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/237#issuecomment-9815737.

[metaskills]

Yes, there is a new cache at the adapter level too which ActiveRecord's reset_column_information hooks into. Any luck in dealing with this in prior versions and migration should be considered luck. Like @jrafanie says, just follow best practice. Remember too, even in Rails 1.0, I was always taught to make local class in your migration class to avoid this.

class DoSomethingToItems < ActiveRecord::Migration
  class Item < ActiveRecord::Base ; self.table_name = :items ; end
  def up
    ...
  end
  def down
    #...
  end
end

Closing this issue.

[jacob-carlborg]

I'm not at work now but as far as I know we don't use the models at all in the migrations.

[jacob-carlborg]

I've checked at work now and we're not using any model in any previous migration.

[metaskills]

Please investigate this and see if you can come up with a solution. Looking at t he code, rename_column uses a helper method of ours called detect_column_for! which uses an instance of the SchemaCache. The #columns method on that object should delegate right back to the connection.columns(table_name) in the adapter just as if a model was reflecting on the schema.

[jacob-carlborg]

I figured out that much, but that's what I think look so strange. columns on SchemaCache is a stored attribute. This attribute is set when a SchemaCache is created. The only place I can find where an instance of SchemaCache is created is in the constructor for the sqlserver adapter and the abstract adapter. I don't understand how the data for the columns in the schema cache gets updated.

[metaskills]

Bundle open activerecord and look at schema_cache.rb, you will see in there that columns is a hash with a key miss block supplied that performs the logic.

[jacob-carlborg]

Oh, right, that's what it is. Now that I know how that works I'll keep looking.