Si quieres hacer toda la migración a la vez, mongoid_rails_migrations hará lo que necesites. No hay mucho que documentar, duplica la funcionalidad de la migración estándar de ActiveRecord. Usted escribe sus migraciones, y luego usa rake db:migrate para aplicarlas y se encarga de averiguar cuáles se han ejecutado y cuáles no. Puedo responder más preguntas si hay algo específico que desea saber al respecto.
Para las migraciones diferidas, la solución más fácil es utilizar la devolución de llamada after_initialize. Comprobar si un campo coincide con el esquema de los datos de edad, y si lo hace lo modifica el objeto y su actualización, así por ejemplo:
class Person
include Mongoid::Document
after_initialize :migrate_data
field :name, :type => String
def migrate_data
if !self[:first_name].blank? or !self[:last_name].blank?
self.set(:name, "#{self[:first_name]} #{self[:last_name]}".strip)
self.remove_attribute(:first_name)
self.remove_attribute(:last_name)
end
end
end
Las ventajas y desventajas a tener en cuenta con el enfoque específico que di arriba:
Si ejecuta una solicitud que devuelve muchos registros, como Person.all.each {|p| puts p.name} y 100 personas tienen el formato antiguo, inmediatamente ejecutará 100 consultas de conjunto. También puede llamar al self.name = "#{self.first_name} #{self.last_name}".strip, pero eso significa que sus datos solo se migrarán si se guarda el registro.
Los problemas generales que puede tener es que las consultas masivas como Person.where(:name => /Foo/).count fallarán hasta que todos los datos se migren. Además, si lo hace Person.only(:name).first, la migración fallaría porque olvidó incluir los campos first_name y last_name.
No creo migraciones perezosos son una buena idea. Prefiero tomarme el tiempo para ejecutar una actualización masiva de datos, esperar a que se complete, supervisar, pensar en una forma de revertir si algo sale mal, y probarlo primero en un clon de base de datos. Lleva tiempo, pero no te dejará con inconsistencia de datos. –