Полезность db миграции отката

Question

Многие люди говорят о миграции db, особенно о возможности его отката.

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

Предположим, что я сделал откат некоторой миграции. И что ? Приложение не будет работать, потому что его логика полностью зависит от db.

Каковы возможности отката для миграции db?

---

Update 1

Главный вопрос

Почему Откат представлена ​​как функция, когда мне нужно изменить код?

Я не создать миграции, как "add_another_field_to_table". Вместо этого каждый файл миграции полностью описывает каждую таблицу в БД. Когда мне нужно что-то изменить в моей БД, я просто изменяю файл миграции, но не откатывайте его обратно.

Действительно, если я откатываю миграцию, он не возвращает меня вовремя, как и управление версией. У меня много работы, когда изменения планируются, а откат ничего мне не дает.

Answer 1

Точка отката - это то, что вы одновременно выполняете код отката и DB. Сценарий заключается в том, что вы обновляете свой код и свою базу данных на своем производственном сервере, тогда вы обнаружите ошибку, и вам действительно нужно вернуться. Поэтому откат вашего кода и использование переноса вниз для отката вашей БД.

Answer 2

Не понимаю вашу проблему, но я пытаюсь немного объяснить ее откатом. Откат выполняется, если вы хотите отменить изменения путем соответствующей миграции. Это означает, что база данных будет изменена, а также ваш schema.rb будет автоматически восстановлен. Когда вы это сделаете, вероятно, вы также захотите удалить ссылочный код. Например, если вы удалили поле из модели, возможно, вы не хотите ссылаться на этот атрибут в своем коде. Если вы попытаетесь получить доступ, то вы получите неопределенное исключение атрибута. Вот и все. Может стать немного громоздким для отката, например, если вы создали некоторые миграции модели 10 раньше, и вы хотите изменить некоторые поля. Лучше создать новую миграцию и изменить там, вместо того, чтобы вернуться к соответствующей миграции.

Update 1

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

1. Вернитесь к соответствующей миграции.(rake db:migrate VERSION=XXX, мне нравится лучше rake db:rollback STEP = 2, например, откатывает 2 миграции, STEP опционально)
2. Внесите изменения
3. перенастройки базы данных, чтобы обновить все таблицы и получить к текущей версии миграции. (rake db:migrate)

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

Answer 3

В чем смысл миграции Up?

1. Вы создаете структуры таблицы.
2. Вы код вокруг него, он работает хорошо.
3. Вы вводите сайт в эксплуатацию, все довольны.
4. О, подождите, им нужна новая функция, которая включает добавление столбца в существующую таблицу.

Как вы справляетесь с этим? Вы должны добавить столбец в свои таблицы разработки, тестовый код, обновить сайт в реальном времени, не забывая одновременно обновлять живую БД (потому что, если вы делаете, будут большие ошибки), а также помните, чтобы сохранить существующие данные в реальном времени. Этот аспект управления БД может быть настоящей болью без хорошего управляемого решения, такого как рельсы.

Итак ...

1. Код одна линии миграция, что добавляет столбец
2. Выполнить миграцию на Dev копии, scehma.rb обновит
3. кода новых функций, если вам нужно проверить DB schema use schema.rb НЕ файлы миграции.

Теперь вы готовы выпустить на производство .... код

1. Update на производство
2. Выполнить миграцию на производство. Rails автоматически определит, что нужно применять и сделать это за вас!

Несомненно, при добавлении одного столбца это не так смущает сделать это самостоятельно.

Но что, если было 3 программиста, добавляющих миграцию? Что делать, если у вас много живых сайтов, все в разных версиях? Является ли этот живой сайт 2 или 17 миграциями позади? Что мне нужно сделать, чтобы получить БД до последнего кода, сохраняя данные в реальном времени? Можете ли вы понять, как это очень быстро сбивает с толку?

Рельсы миграции (и практически каждая миграционная система работает на тех же принципах) предназначены для того, чтобы упростить обновление структур БД. Хорошо стоит использовать правильно.

Answer 4

Рассмотрите сценарий, в котором вы используете capistrano для развертывания вашего сайта и создания временных снимков каждого развертывания. Используя временную метку в папке и ваших миграциях, вы можете определить, какие версии кода и схемы идут рука об руку и выполняют откат.

Репозиторий git предоставит вам аналогичные варианты.

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

Answer 5

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

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

Answer 6

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