DeleteOne, DeleteMany и мягкое удаление

Глагол удаления в драйвере самый скупой на церемонии: coll.DeleteOne(ctx, filter) возвращает (*DeleteResult, error) с одним полем DeletedCount. Совпадение не нашлось — счётчик равен нулю и ошибки нет: удаление, в отличие от FindOne из шестого урока, не отвечает ErrNoDocuments на пустоту. Семантика «удалил или нет» читается по числу, а ветка ошибки зарезервирована для настоящих проблем: сети, таймаутов, недоступности сервера — их разбор в двадцатом уроке. DeleteMany устроен так же, только стирает все совпавшие документы и возвращает их общее количество в том же DeleteResult. Оба принимают опции после фильтра: options.DeleteOne() и options.DeleteMany() дают SetHint для подсказки индекса, SetComment для метки в профайлере сервера и SetCollation для правил сравнения строк. Отдельное поле Acknowledged отвечает за подтверждённость записи: при обычной настройке write concern оно всегда true, а в непризнанных конфигурациях счётчик теряет смысл — это редкий режим, но знать о нём стоит до продакшена. Практическое правило любого mongo delete go-кода: удаляйте по _id или по уникальному индексу, когда это возможно, — такие удаления точечны, дёшевы и не зависят от того, сколько документов накопилось в коллекции за ночь.

DeleteResult — тип-минималист: DeletedCount int64 и больше ничего. Из него принципиально нельзя узнать, какие именно документы были удалены: драйвер получает от сервера только число. Если перед удалением нужны данные документа — не «сначала Find, потом Delete», а FindOneAndDelete: он атомарно удаляет и возвращает документ через знакомый *SingleResult из шестого урока, с Decode и ErrNoDocuments на пустоте. У FindOneAndDelete и опции полезные: SetSort выбирает, какой из совпавших документов стереть, — «самый старый по _id» уходит одним вызовом без предварительного Find, а SetProjection ограничивает набор полей в ответе; сортировка там пишется тем же bson.D, что и везде. Двухшаговая схема Find плюс Delete теряет атомарность между шагами: другой воркер успеет удалить документ первым, и ваш Delete скажет DeletedCount 0 уже после того, как вы прочитали данные, — для логирования это мелочь, для возврата товара на склад — рассинхрон. Второе следствие скупости DeleteResult — безопасность повторов: повторное удаление того же _id вернёт ноль и не упадёт, поэтому ретраи безвредны, а бизнес-логика «документ точно был» должна опираться на счётчик, а не на отсутствие ошибки. Третье следствие — тесты: проверять удаление следует через DeletedCount, а не через отсутствие ошибки, иначе тест пропустит ситуацию «фильтр не совпал», которая на проде означает невыполненное требование.

Фильтр bson.M{} в Find вернёт всю коллекцию, а в DeleteMany — её сотрёт. Разница в цене ошибки делает пустой фильтр delete-вызова особой строкой в код-ревью. Типовой сценарий аварии: функция чистки получает фильтр из переменной, переменная инициализируется позже и остаётся nil или пустой, DeleteMany честно выполняется по всем документам. Второй сценарий — параметризованная фильтрация с «опциональными» условиями: исключили всё, фильтр схлопнулся в пустой документ, и массовое удаление прошло по всей коллекции. Защита живёт на стороне кода: фильтры для удаления собирать отдельными функциями, которые не возвращают пустой документ в принципе; в критичных местах закладывать в фильтр обязательное окно по updated_at; и никогда не игнорировать число из лога «удалено N» — аномально большое N должно кричать в мониторинге. MongoDB, кстати, подтверждения не спросит: mongosh с его удалением по Enter — единственное место, где база переспросит, драйвер выполняет команду молча. Поэтому барьер обязан стоять в коде и в процессе ревью, а не в интерфейсе базы.

Мягкое удаление — не отдельный глагол драйвера, а соглашение: документ помечается меткой времени, и читающие запросы фильтруют метку. Модель получает DeletedAt *time.Time с тегом deleted_at,omitempty: nil значит «жив», указатель — потому что нулевое время и «метки нет» разные вещи, эта история уже была в пятом уроке. Само удаление — UpdateOne с $set: bson.M{"deleted_at": time.Now()}. А вот читающие запросы меняются все без исключения: каждый Find обязан добавлять условие "deleted_at": nil, иначе мёртвые документы просачиваются в выдачи. Полдюжины мест, где надо помнить об условии, — полдюжины шансов забыть, поэтому условие прячут в слой репозитория: метод-конструктор фильтра добавляет его автоматически, а сырые вызовы коллекции из бизнес-кода запрещают линтом и ревью. Приём называется soft delete, и mongodb-сообщество сходится в одном: пометка — половина решения, вторая половина — дисциплина чтения. Без неё мягкое удаление превращается в медленную утечку данных в отчёты: помеченные записи всплывают в списках, счётчиках и экспортах, а исправлять это приходится точечно, по мере жалоб.

Физическое удаление дешевле в поддержке: никакой лишней логики в каждом запросе, никакой растущей коллекции, и закон о персональных данных получает то, что просит, — данные действительно исчезают. Мягкое удаление покупает восстановление и историю: «случайно удалили номенклатуру» лечится одним апдейтом вместо подъёма бэкапа за ночь, аудиторам можно показать, что и когда помечалось, а основная коллекция остаётся единственным источником правды — точечное восстановление не требует поднимать копию базы целиком. На проде чаще всего живёт комбинация: пометка deleted_at сразу и физическое стирание позже — фоновая задача по расписанию или по запросу субъекта данных. Стирание старьёвки удобно делегировать серверу: TTL-индекс удаляет документы по истечении срока, и семнадцатый урок покажет его через CreateOne. Запрос «mongo delete go» приводит в этот раздел чаще всего не за синтаксисом, а за ответом «а как у вас»: у платежных записей долгая жизнь и редкое удаление, корзины и сессии умирают по TTL с рождения, каталоги живут на soft delete с ручной чисткой. Плох только один вариант — «у нас удаление и так работает» без ответа на вопрос, кто и как посмотрит на удалённое завтра.