2010-06-05 1 views
20

Теперь, когда Rails имеет timestamped migrations, номер одной версии в верхней части /db/schema.rb кажется бессмысленным. Иногда номер версии оказывается неверным при работе с несколькими разработчиками или несколькими ветвями.Rails: Используется ли номер версии в 'schema.rb' для чего-либо?

Может ли Rails использовать этот параметр :version?

И есть ли вред в том, что он неверен (как в: он не отражает отметку времени последней применяемой фиксации)?

Пример:

ActiveRecord::Schema.define(:version => 20100417022947) do 
    # schema definition ... 
end 

ответ

27

На самом деле, версия является гораздо более важным, чем это. Код, который вы указали, на самом деле является лишь малой частью того, что делает pred_migrated_upto_version. Реальный эффект версии миграции заключается в том, что все предшествующие миграции(как указано в каталоге db/migrate) Предполагается, что запущены. (Так что да, это то, что предлагает название функции.)

Это имеет некоторые интересные последствия, особенно в том случае, когда несколько человек совершают новые миграции одновременно.

Если вы используете версию schema.rb, то, что рекомендует команда Rails, вы в порядке. У вас на 100% гарантировано наличие конфликта (версия схемы), и пользователь, совершающий/слияния, должен решить его, объединив свои изменения и установив версию: на самую высокую из двух. Надеюсь, они правильно это сделают.

Некоторые проекты позволяют избежать этой проблемы непрерывного конфликта, сохранив schema.rb вне контроля версий. Они могут полагаться исключительно на миграцию или сохранять отдельную версию схемы, контролируемой версиями, которую они время от времени обновляют.

Проблема возникает, если кто-то создает миграцию с отметкой времени до в версию schema.rb's: version. Если вы выполните db: migrate, вы примените их миграцию, ваш schema.rb будет обновлен (но сохраните ту же, более высокую версию), и все будет в порядке. Но если вы должны произойти с db: schema: load (или db: reset) вместо этого, вы не только пропустите их перенос, но Предположите, что pred_migrated_upto_version отметит, что их миграция была применена.

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

В идеале, я бы предпочел, чтобы схема schema.rb фактически содержала список примененных номеров миграции, а не версию «Пред-вверх-сюда: здесь». Но я сомневаюсь, что это произойдет - команда Rails, похоже, считает, что проблема адекватно решена путем проверки в файле schema.rb.

+0

Вы правы, это похоже на Rails 2.3. * И 3.0.* Интересно, есть ли у них билет, открытый для этого. –

+0

Добавлен Rails Ticket: https://rails.lighthouseapp.com/projects/8994-ruby-on-rails/tickets/5883 –

+4

Я не уверен, был ли этот ответ правильным, но похоже, что его больше нет , Раздел «Что находится в имени» в http://guides.rubyonrails.org/migrations.html#what-s-in-a-name делает достаточно ясным, что Rails попытается выполнить любые миграции, которые еще не были запущены. .. даже если была произведена более поздняя миграция. –

4

я решил исследовать себя. Оказывается, из-за временных привязок только Rails делает с этим числом Предположим, что миграция с этой конкретной меткой времени уже была применена и, таким образом, создать соответствующую запись в таблице schema_migration, если она не существовать.

от: /lib/active_record/connection_adapters/abstract/schema_statements.rb

def assume_migrated_upto_version(version, migrations_path = ActiveRecord::Migrator.migrations_path) 
    # other code ... 
    unless migrated.include?(version) 
     execute "INSERT INTO #{sm_table} (version) VALUES ('#{version}')" 
    end 
    # ... 

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

  • Нет связанных вопросов^_^