Оптимизация)

Нет, это даже оптимизацией не назовёшь. Быстрее было бы ничего не обновлять, если документа больше нет в базе.

Делать update тех полей что изменились - это нормально. А вот upsert - нет.

Хороший разбор

Собеседование наоборот: вопросы соискателя к компании.

«Хочу очередной раз поднять тему про найм. Только я собираюсь поговорить об этом с точки зрения кандидата, а не работодателя. Ведь собеседование, вопреки многим стереотипам, процесс двусторонний»: http://amp.gs/20Io

Да, особенно можно "козырнуть" вопросом
"Есть ли у вас стратегия развития? Что в ней запланировано через 2 года?"
в ответ на вопрос к тебе "Кем вы видите себя через 5 лет?"

Mongoengine как семь лет назад был ненужной поделкой, созданной для того, чтобы отворотить от монги, так, кажется, ей и остался.

Начинаете новый проект — возмите мой ODM. Как раз после косякоа ME написал.
Он плохо документарован и, местами, не идеален, но всяко лучше ME. Плюс есть я, который помочь в трудную и не очень минуту.
https://github.com/zzzsochi/yadm

Видимо да. Мне он удобен тем что можно описать схему документа  (о нет, схема для монги, какое кощунство!) и не возюкаться в коде со словариками через раз используя .get(key, default)

Вот для этого я YADM и написал — объекты со схемой, вместо словариков.

При том, я не стал калечить язык запросов джанго-лайк-эктив-рекордами и сделал всё максимально прямолинейно.

Но полноценные кверисеты присутствуют. Ибо удобно.

Есть ещё у меня "великая проблема" с самой MongoDB. Это создание коллекций с индексами (особенно уникальными). Как это сделать вызвав команду создания всего вот этого только один раз, и при этом сделать это гарантированно до того, как хотя бы один документ попадёт в эту коллекцию.
Фишка в том, что коллекция создаётся в монге автоматом при первом же запросе на добавление или измененние документа в ней. И если не успеть создать уникальный индекс, то можно получить дубликаты и потом хрен ты этот индекс создашь.

В Mongoengine сделали супер тупо - можно в модели указать автоматическое создание индексов, и тогда mongoengine на каждый вызов save будет вызывать создание индексов. На каждый, Карл!
Монга конечно не совсем дура, и не пересоздаёт уже существующие индексы, но тем не менее лишний запрос на каждый save документа.

Есть конечно ещё один варинат - перед тем как запустить основное приложение на всех 100500 серверах, надо выполнить скрипт, который создаст все коллекции с индексами. Топорно, не удобно, увеличивает off-time при обновлениях приложения, но вполне работает.

Мне кажется для метода с именем save как раз нормально заново вставлять объект. То что подефолту улетают не все поля, это больше странно. Такое обычно за опцией прячут.

Тут проблема больше в том, что вместо одного метода save лучше сделать два create и update.

Для Django  ты тоже считаешь был бы нормально если save() использовал UPSERT?

Ты так часто создаёшь коллекции?
Я по этому поводу вообще не парюсь. Если надо что-то кастомное, то иду в базу и делаю до того, как отправлю код. Один раз, кажется, приходилось...
А обычно — пусть запись начинается. Потом иду в базу и дёргаю создание нужных индексов. Всё максимально тупо.

Как по мне это совсем не очевидное поведенеие

Я считаю само существование двойственного метода save проблемой.

Я тут скорее считаю проблемой само удаление объектов из базы...

У нас 4-5 стендов на которых развёрнуто приложение, и они обновляются не всегда одновременно. Иногда может много времени пройти между тем как выпустим новый релиз и тем как мы обновим один из стендов.
Очень не хочется помнить все детали того, что надо сделать на стенде ручками прежде чем выкатитить обновление. Хочется просто нажать в Jenkins кнопку и что бы оно выкатилось без ручной работы.