Estoy creando una aplicación Rails 3.2 en una base de datos heredada que también tiene algunos registros rotos en diferentes tablas. Uno de los problemas que da más dolor de cabeza es que incluye fechas no válidas.

He configurado una caja de arena que arreglé manualmente una vez para que mi código funcione. Ahora es el momento de la implementación. Por este motivo, el recinto de seguridad se restablece cada noche y se copia de la base de datos activa, los índices de hurón se reconstruyen y las migraciones se vuelven a aplicar. Vamos a implementar en el recinto de seguridad con frecuencia para obtener los últimos arreglos antes de implementar la configuración en vivo.

Como la aplicación PHP heredada y esta nueva aplicación de Rails deben ejecutarse en paralelo durante algunas semanas o meses, no podemos simplemente fijar las fechas una sola vez (Actualizar: solo para aclarar, eso significa que se ejecutan en la misma base de datos al mismo tiempo). Necesito una forma de automatizar esto, tal vez con una tarea de migración o rake (me gustaría ir a este último).

Pero el problema es: ActiveRecord se atraganta con la carga de dichos registros, por lo que no tengo forma de investigar el registro y fijar las fechas mediante algunas suposiciones codificadas en el código Ruby.

Un segundo problema es que la base de datos heredada tiene inconsistencias porque el código PHP no usó transacciones y algunas rutas de código están rotas y quedan huérfanos y restricciones de tablas rotas. Me ocuparé de que a medida que se produzcan, la mayoría de ellos ya estén atendidos en los modelos. El primer problema va con las fechas.

¿Cómo solías arreglar esto? Tal vez haya incluso alguna joya mágica que admita la migración de bases de datos heredadas con registros rotos al interceptar excepciones y ejecutar algún código de prueba de reparación ...

La ruta de migración utiliza MySQL y tres entornos de producción (estables con base de datos en vivo, con la misma base de datos y sandbox con un reinicio de clonación de base de datos cada noche). Decidimos no realizar una única migración / mapeo de datos porque no podemos reemplazar la aplicación heredada completa en un solo paso (consiste en un CMS con aproximadamente 50000 artículos, cientos de temas, una enorme base de datos de archivos con imágenes y descargas, que admite aproximadamente 10 sitios web , alrededor de 12 años de datos y trabajo, código PHP desordenado de diferentes habilidades de programación, código duplicado de diferentes etapas de migración, extrayendo contenido RSS de sitios asociados para mezclar artículos / publicaciones de allí en las líneas de tiempo del artículo en los temas de nuestra propia aplicación, y mucho más cosas divertidas ...

El primer paso es migrar la aplicación backend para obtener una interfaz de administración y publicación coherente. Las aplicaciones frontend heredadas aún deben escribir en la base de datos (comentarios y otro contenido creado por los visitantes). Por lo tanto, el proceso de reparación de la base de datos debe poder ejecutarse sin supervisión de forma regular.

Ya tenemos arreglos en el lugar que manejan con gracia las dependencias de modelos rotos en belongs_to y has_many. La integración de Paperclip se ha diseñado para funcionar con todos los fantásticos mapeos de nombre de archivo inventados. Y la gema del freno de aire informa de todos los bloqueos de aplicaciones en nuestra instalación de redmine, por lo que obtenemos una visión general rápida de todos los caprichos de la izquierda.

Las aplicaciones heredadas ya se han modificado para que funcionen con la última versión de MySQL y se han migrado a un servidor de bases de datos MySQL actual.