А как? Фильтровать по полю is deleted?

Потому, эту проблему с save вообще никак не обрабатываю. Кроме того, что там будет сохранён весь объект целиком, а не только изменившиеся поля. Раньше у меня такой функционал был, но потом я вырезал за ненужностбю.

Для чего-то с именем save не может быть очевидного поведения.

Мы используем removed, да. Нас не раз такой подход спасал от проблем.  Удаление это всегда опасная операция и я стараюсь без неё обходится. Пока успешно.

Ну почему же? Дефолтное поведение монги вполне очевидно: замена или создание объекта. Это ME выделывается, пытаясь минимизировать изменяемые поля, что делает поведение не очевидным.

И поскольку все вложенное в один документ нет проблемы каскадного удаления, чтобы removed флаг ставить в нескольких коллекциях?

Миграции.   🙂

Ну вот именно в Mongoengine оно по документации должно делать обновление если документ уже существует, и вставлять его - если не существует.
Но видимо сначала они сделали классическую оптимизацию по обновлению только изменившихся полей (думаю так делают все ORM). А потом почему-то решили делать upsert если юзер сам не добавил доп. условия для обновления. Мне совсем не понятно зачем они такое сделали и при этом сделали криво, забыв про то что  в запросе нет всех нужных полей, а только те, что изменились.

Нет проблем ставить removed где угодно и сколько угодно. Говорю как серийный монговод.

Это не поведение монги. По дефолту монга делает именно update. upsert надо включать отдельной опцией

Кажется, что нет. Если мы говорим про метод save...

Есть апдейт, у которого есть опциональный апсерт, а есть сейв, который внутри тоже апдейт, но с апсертом.

Жалко что нет нормальной реализации для монги. Надо самому их писать. А если у тебя приложение это библиотека-ядро, которое используется в отдельных приложениях-кастомизациях, то надо писать это хорошо, по взрослому. Что бы можно было добавлять миграции "снаружи".

Да и не нужна какая-то особая реализация для монги. В общем случае это просто скриптик, который должен запуститься до запуска новой версии приложения.

Запуститься из CI, конечно же.

У меня для этого есть свой костылик, но его стыдно показывать: https://github.com/zzzsochi/migranite
Написал за вечер в баре...

Пять лет назад... Офигеть время летит. Это я уже пять лет хочу поправить там схему подключения монги...

Это слишком простой взгляд на вещи. Вот у нас есть ядро, в котором есть свои миграции. У ядра есть разные версии - значит надо хранить все миграции, что бы можно было выполнить обновление перескочив через несколько релизов.
Ядро используется в кастомизациях, где тоже могут быть миграции и их тоже надо как-то хранить и запускать согласованно с миграциями в ядре.
Для ядра мы сделали аля супер-простой South для джанги - все миграции это скрипты в одной папке и есть коллекция, в которой храним список уже отработаных миграций. Но не хватает возможности добавлять миграции "снаружи", из кастомизаций, которые используют ядро как зависимость.

> все миграции это скрипты в одной папке и есть коллекция, в которой храним список уже отработаных миграций
Вот как раз мигранит это и делает.

И, в общем случае, это всё, что от такой системы требуется. Нам хватает за глаза.