Как сценарии миграции применяются в Rails 2.1 и выше?

Question

Я не являюсь разработчиком Rails (в настоящее время), поэтому, пожалуйста, прости мое невежество по этому поводу.

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

Rails 2.1 и выше, насколько я могу судить, внес два изменения в логику миграции. Первым было использовать имена сценариев на основе меток времени при их создании, чтобы уменьшить вероятность того, что 2 разработчика работают над одним файлом одновременно, прежде чем добавлять файл в систему контроля версий. Таким образом, вместо 002_test.rb теперь генерируется сценарий 20090729123456_test.rb.

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

Просматривая источник Rails, я заметил, что для текущей версии схемы в качестве максимальной версии, найденной в таблице Schema_Migration, выбрано.

Вот сценарий, который я пытаюсь выяснить:

Разработчик А создает новый скрипт: 20090729120000_test.rb.

Разработчик B создает новый скрипт: 20090729130000_test.rb.

Разработчик B сначала переносит свой сценарий в базу данных, не указывая номер версии и предполагая, что сценарий разработчика A еще не добавлен.

Что происходит, когда Разработчик A добавляет свой сценарий и пытается перейти на последнюю версию, поскольку его версия сценария (на основе отметки времени) меньше, чем текущая применяемая версия сейчас?

Answer 1

Я не уверен, но я считаю, что ему придется выполнить "rake db: rollback", чтобы отменить миграцию Developer B, а затем запустить "rake db: migrate", чтобы сделать их оба в правильном порядке. Конечно, если два разработчика работают независимо над таблицами, которые не требуют интеграции друг с другом (как показывает этот случай, так как разработчику B не нужно было ждать, пока разработчик A выполнит свою миграцию), разработчик A может просто добавить один к метка времени миграции разработчика B. И она снова будет в правильном порядке.

Answer 2

Короткий ответ: не беспокойтесь об этом.

rake db: migrate попытается выполнить любые миграции, которые не найдены в таблице schema_migrations. Не имеет значения, есть ли новые миграции, которые уже были выполнены.

Если B зависит от A и должен выполняться в таком порядке, у вас может быть проблема, но это проблема между разработчиками.