2016-11-23 4 views
3

У меня есть экземпляр MongoDB 3.2, работающий на Ubuntu 14.04. Установлен один узел. Прошлой ночью я провел миграции, где я побежал этот код для ~ 1400 документов в коллекции:

for r in responses: # find cursor with ~1400 documents in it 
    database.responses.update_one({ 
     "_id" : r["_id"] 
    }, { 
     "$set" : { 
      "client_id" : client["_id"] 
     } 
    }) 

После миграции, некоторые из полей в моих документах реагирования в responses коллекции перешли от DateObject типов до Int32 метки времени представления. Некоторые из полей Int32 были изменены на Double с. Эти поля не были обновлены в моем заявлении $set (очевидно). Это повлияло только на небольшое подмножество курсора (~ 75 документов).

Это вызвало катастрофический отказ, поскольку наши модели ожидали, что эти поля будут иметь типы данных, которых они больше не имели. Может кто-нибудь объяснить мне, что здесь не так?

ответ

0

после прочтения вашего вопроса, я получил любопытно узнать, что пошло не так, я думаю, если вы явно сидели тип в создании/обновлении этих записей вы бы не столкнулись с этой проблемой, например: -

for r in responses: # find cursor with ~1400 documents in it 
database.responses.update_one({ 
    "_id" : r["_id"] 
}, { 
    "$set" : { 
     "client_id" : new DateObject(client["_id"]); 
    } 
}) 
+0

'client_id' уже имеет тип ObjectId и не был затронут одним из полей, но спасибо! –

0

Мое предположение заключается в том, что где-то в вашем коде python вносил изменения в типы (возможно, какой-то код, который пытается автоматически вывести тип!?).

Я уверен, что перед вашим кодом «for r in response:» есть что-то еще, что, возможно, пытается определить тип полей. Это так? Можете ли вы предоставить код перед предоставленным фрагментом?

+0

Это может быть Pymongo, библиотека MongoDB, которую я использую, но это никогда не делалось раньше ... Объекты в списке 'response' - это объект-курсор с результатами Pymongo (BSON dicts) –

Смежные вопросы