Подтвердить что ты не робот

Rails: Используется ли номер версии в 'schema.rb' для чего-либо?

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

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

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

Пример:

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

Ответ 1

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

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

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

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

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

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

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

Ответ 2

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

from: /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
    # ...