Я бы сказал сначала написать функцию (или метод, или класс), которая преобразует документы старого стиля в документы нового стиля, а также корректно обрабатывает нерелевантные документы (например, проектный документ), если это необходимо.Напишите несколько модульных тестов, пока вы не будете уверены в этом коде.
Следующий шаг - это цикл поиска документов старого стиля и их обновления до документов нового стиля с использованием процедуры модификации.
Если у вас небольшой набор данных, вы можете просто запросить /_all_docs?include_docs=true
и работать со всем вашим набором данных в одном пакете.Если у вас есть больший набор данных, возможно, напишите представление, которое идентифицирует документы старого стиля
function(doc) {
// map function for "to_do" view
if(doc.parameters && typeof doc.parameters == "string")
emit(doc._id, doc)
}
Это представление покажет вам все документы старого стиля для выполнения .Чтобы получить еще 50 документов для конвертации, GET /my_db/_design/converter/_view/to_do?limit=50
.Поле "value"
каждой строки будет полной копией документа, поэтому вы можете сразу же запустить его с помощью функции конвертера.
После преобразования документа вы можете либо отправить его обратно в базу данных, либо создатьдо партии и используйте _bulk_docs
, чтобы сделать то же самое.(Bulk docs - это то же самое, только немного быстрее.) При сохранении каждого документа он исчезает из представления to_do
.(Если вы получили ошибку 409 Conflict
, просто игнорируйте ее.) Повторяйте эту процедуру, пока в to_do
не будет 0 строк, и все готово!
Вы можете судить по вашей ситуации, насколько осторожны вынужно быть.Если это производственные данные, вам лучше написать хорошие юнит-тесты!Если это среда разработки, просто сделайте это!
Последний трюк - создать новую пустую базу данных и скопировать в нее основную базу данных.Теперь у вас есть двойная песочница, чтобы попробовать свои идеи.Вы можете удалять и повторять свою песочницу, пока не будете удовлетворены результатами.