2010-06-18 2 views
2

Я пытаюсь обновить старое приложение 1.2.6 Rails до 2.3.8, и я столкнулся с некоторой проблемой с миграциями. А именно, если в миграции есть что-то вроде ModelName.create (: foo => "bar"), миграция не завершается. Он не попадает в бесконечный цикл или что-то еще. Он просто отказывается завершить эту миграцию.Что может привести к тому, что эта миграция зависает?

Вот пример кода.

Это работает:

class CreateNewsArticles < ActiveRecord::Migration 
    def self.up 
    create_table :news_articles, :force => true do |t| 
     t.string "name" 
     t.string "image" 
     t.text "body" 
     t.boolean "featured", :default => "0" 
     t.integer "position" 
     t.timestamps 
    end 
    # Section.create(:name => 'News Articles', :controller => 'news_articles', :description => 'Add, edit, and delete news articles.') 
    end 

    def self.down 
    drop_table :news_articles 
    Section.find_by_name('News Articles').destroy 
    end 
end 

раскомментирован Section.create (...) означает, что миграция никогда не завершается.

Вот выход из передней дб: мигрировать --trace:

** Invoke db:migrate (first_time) 
** Invoke environment (first_time) 
** Execute environment 
** Execute db:migrate 
== CreateNewsArticles: migrating ============================================= 
-- create_table(:news_articles, {:force=>true}) 
    -> 0.0531s 

И после того, как закомментировать Section.create

** Invoke db:migrate (first_time) 
** Invoke environment (first_time) 
** Execute environment 
** Execute db:migrate 
== CreateNewsArticles: migrating ============================================= 
-- create_table(:news_articles, {:force=>true}) 
    -> 0.0479s 
== CreateNewsArticles: migrated (0.0481s) ==================================== 

** Invoke db:schema:dump (first_time) 
** Invoke environment 
** Execute db:schema:dump 

Я попытался это на другом компьютере, и она работает , Одинаковая версия рейка, ту же версию рубинов и рельсов замораживается.

грабли --version: rake, version 0.8.7, рубин -v: ruby 1.8.6 (2010-02-05 patchlevel 399) [i686-darwin10.3.0], рельсы -v: Rails 2.3.8

Кто-нибудь есть какие-нибудь идеи?

ответ

0

Видимо, используя рубин 1.8.6-p399 был виновником. Переключение на 1.8.6-p369 решило это.

+0

вы заботитесь бы уточнить, почему это решило его или где вы нашли такое решение ! –

0

Вы также можете попробовать определить модель раздела штриховых костей в процессе миграции.

+0

Проблема заключается в том, что миграция не может найти модель раздела? Кажется странным, что она просто выйдет без ошибки. – ahlatimer

+0

Я не уверен, что я просто пытаюсь, когда миграция становится странной. Особенно полезно, если модель имеет информацию о старой схеме. – thomasfedb

8

Вы можете увидеть один и тот же симптом из другой причины: миграция может повиснуть, если вы работаете:

$ rails console --sandbox 

в другом процессе. Выход из процесса консоли позволяет завершить миграцию.

+2

Bullseye! Спасибо! – jibiel

+0

Это исправило мою проблему - но моя висела до того, как она попала на линию времени, в отличие от проблемы OP. Когда консоль была заморожена, я не мог завершить процесс в консоли - Ctrl + C не оказал никакого эффекта. Пришлось закрыть окно терминала, чтобы убить процесс.Как только я оставил консоль для песочницы в другом терминале, мой db был окончательно запутан - rollback/migrate не работал, поскольку первоначальная миграция была убита без возможности изящно умереть. Мне пришлось откат к миграции, создав таблицу, вызывающую проблему, прежде чем я смогу перейти. – guiniveretoo

2

У меня была такая же проблема .. я узнал, что там была простой сделка, которая блокировала дальнейшие запросы по этой таблице ..

Пробег:

heroku pg:ps 

Для просмотра процессов базы данных. Вам придется убить простой процесса:

heroku pg:kill 913 --force -a 

(913 является ID простоем процесса -> изменить его к вашим потребностям

Смежные вопросы