Можно ли использовать Rails Migrations для преобразования данных?
Если вы хотите использовать свой собственный формат вывода, вы также сможете получить желаемое поведение с помощью RDD.
Посмотрите на следующие классы: FileOutputFormat , FileOutputCommitter
В формате выходного файла у вас есть метод с именем checkOutputSpecs, который проверяет, существует ли выходной каталог. В FileOutputCommitter у вас есть commitJob, который обычно переносит данные из временного каталога в свое конечное место.
Я еще не смог его проверить (сделаю это, как только у меня будет несколько бесплатных минут) но теоретически: если я расширяю FileOutputFormat и переопределяю checkOutputSpecs на метод, который не генерирует исключение в каталоге, уже существует, и отредактируйте метод commitJob моего пользовательского обработчика вывода для выполнения той логики, которую я хочу (например, переопределить некоторые из файлов, добавьте другие), чем я также смогу добиться желаемого поведения с помощью RDD.
Формат вывода передается в: saveAsNewAPIHadoopFile (который также называется методом saveAsTextFile, чтобы фактически сохранить файлы). И коммиттер вывода настроен на уровне приложения.
3 ответа
То, что вы пытаетесь сделать, возможно, и я бы сказал, что это правильно.
Однако вам нужно перезагрузить информацию столбца для классов модели вы обновляете в процессе миграции, чтобы Rails знал о новых столбцах. Попробуйте следующее:
def.self up
add_column :users, :age_text, :string
User.reset_column_information
users = User.find(:all)
users.each do |u|
u.age_text = convert_to_text(u.age)
u.save
end
end
Отдельно обратите внимание на то, что если ваша таблица большая, обновление одного за другим займет очень много времени .. Будьте осторожны с этим.
Поскольку я здесь новичок, я не могу комментировать вышеизложенное, поэтому я добавлю свой собственный ответ.
В общем, манипулирование данными при миграциях - ПЛОХАЯ идея. Миграции с прямым доступом к модели могут застрять, если логика модели изменится.
Представьте, что во время второй миграции вы добавили новый столбец. Вы хотите заполнить этот столбец новыми данными.
Также предположим, что несколько недель спустя вы добавляете новую проверку в модель - проверку, которая работает с полем, которое еще не существует во второй миграции. если бы вы когда-либо создавали базу данных из миграции 0, у вас были бы некоторые проблемы.
Я настоятельно рекомендую использовать миграции для изменения столбцов и другие средства для управления данными базы данных, особенно при переходе к производственной среде.
Я бы сказал, что если вы можете «отменить» импортированные данные при откате версии миграции, то уместно поместить импорт в миграция.
Например, у меня есть миграция, которая устанавливает множество таблиц поиска и других метаданных. Данные для этих таблиц заполняются на этом этапе. По мере изменения данных для этих таблиц поиска я создаю новые файлы YAML, хранящие метаданные, и загружаю эти файлы в последующих миграциях (и отменяю эти YAMLS, повторно загружая предыдущий файл YAML при резервном копировании из версии миграции). Это довольно чисто. У меня есть файлы (в моем случае в разных четко определенных папках) с этими файлами:
002_setup_meta_data.rb
002_meta_data.yaml
007_change_meta_data.rb
007_meta_data.yaml
Если вы импортируете "производство" данные из другой системы в транзакционные (нестатические) таблицы, тогда я бы сказал, что использование миграции нецелесообразно. Тогда я последовал бы совету Брайана Хогана использовать задачи с граблями.