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

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

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

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

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

Как бы вы обычно это исправляли? Может бытьЕсть даже какой-то волшебный камень, который поддерживает миграцию устаревших баз данных с испорченными записями, перехватывая исключения и выполняя некоторый код попытки исправить ...

Путь миграции использует MySQL и три производственные среды (стабильные с работающей базой данных, промежуточные с одной и той же базой данных и песочница с клоном базы данных, сбрасываемым каждую ночь). Мы решили не делать одноразовое отображение / миграцию данных, потому что мы не можем заменить полностью унаследованное приложение за один шаг (оно состоит из CMS с около 50000 статей, сотен тем, огромной файловой базы данных с изображениями и загрузками, поддерживает около 10 веб-сайтов около 12 лет работы и данных, грязный PHP-код с различными навыками программирования, дублированный код с разных этапов миграции, загрузка RSS-контента с партнерских сайтов для смешивания статей / постов оттуда в хронологию статей в нашем собственном приложении ».темы и многое другое ...

Первым шагом является миграция внутреннего приложения для получения согласованного интерфейса администратора и публикации. Устаревшие веб-приложения все еще должны записывать в базу данных (комментарии и другой контент, создаваемый посетителями). Таким образом, процесс исправления базы данных должен запускаться без присмотра на регулярной основе.

У нас уже есть исправления, которые изящно обрабатывают неработающие зависимости моделей в принадлежащих_вместе и has_many. Интеграция Paperclip была разработана для работы со всеми фантастическими отображениями имен файлов. И жемчужина airbrake сообщает обо всех сбоях приложений в нашу установку Redmine, поэтому мы получаем краткий обзор всех оставшихся ошибок.

Устаревшие приложения уже были модифицированы для работы с последней версией MySQL и были перенесены на текущий сервер базы данных MySQL.