Фильтры: $eq, $gt, $in и bson.M

Начнём с правила, которое снимает половину вопросов: пара "поле": значение в фильтре — это сравнение на равенство. bson.M{"status": "paid"} и развёрнутый bson.M{"status": bson.M{"$eq": "paid"}} — один и тот же запрос: $eq подразумевается и пишется явно только для симметрии или внутри составных условий. mongo фильтры go-драйвера принимают в любом виде документа: bson.M для набросков, bson.D там, где важен порядок, структуру с тегами, если условие собрано заранее. Сервер читает документ сверху: каждое поле фильтра — отдельное требование, и документ совпадает, только когда выполнены все требования сразу. Это неявный AND, и он покрывает большинство реальных запросов: статус и диапазон цены и наличие — три ключа в одном bson.M. Операторы сравнения вкладываются в значение поля: bson.M{"price": bson.M{"$gt": 1000}} читается как «price больше 1000». Вложенный документ может нести несколько операторов сразу — "$gte" и "$lte" рядом дадут диапазон с включёнными границами. И важная деталь про типы: сравнение в MongoDB строгое по классам BSON-типов — число 42 и строка "42" не равны никогда, зато все числовые типы сравниваются между собой как числа: int32, int64 и double в равенстве совместимы, и в сортировке сервер расставит их по значению, а не по разновидности. Если фильтр «не находит» документ, который глазами есть в коллекции, первым делом проверяйте тип значения в mongosh.

Почему bson.M стал дефолтом для условий: фильтры в девяти случаях из десяти — unordered-документ, где порядок полей не влияет на результат, а компактность map-литерала экономит глаза. bson.m фильтры собираются по двум правилам. Первое: несколько ключей верхнего уровня — это AND; «статус оплачен и сумма от тысячи» пишется двумя ключами, без всяких $and. Второе: все операторы поля живут в одном вложенном документе-значении — и диапазон, и список, и существование. Из этих правил вытекает самое популярное место ошибки у новичков: попытка написать два условия для одного поля двумя ключами. В литерале Go такой код не скомпилируется — duplicate key in map literal, и компилятор прав. Но если фильтр собирается динамически, через добавление в карту, второй m["price"] молча перезапишет первый, и запрос станет короче на одно условие; об этом — отдельный коллаут ниже. Ещё одна тонкость bson.M: ключи — строки, и опечатка в имени поля не поймается нигде до момента, когда запрос вернёт пустоту; поэтому фильтры для постоянных запросов объявляют через переменные с именами полей — var fieldPrice = "price" — или через структуры с тегами. В пятом уроке мы уже договаривались: bson.M законен в тестах и разовых проверках, в продовом коде имя поля обязано прийти из константы.

Неявный AND не умеет «или» — за этим приходит логический оператор $or: он принимает массив условий, из которых достаточно любого. bson.M{"$or": []bson.M{{"status": "paid"}, {"total": bson.M{"$gte": 10000}}}} найдёт и оплаченные, и просто дорогие заказы. Внутри каждого элемента массива действует тот же неявный AND, поэтому ветки получаются сколь угодно сложными. Когда же $and пишут явно? В двух случаях: несколько условий на одно и то же поле — "$and": [{"price": {"$gt": 100}}, {"price": {"$lt": 500}}] — и точный контроль над порядком условий, который иногда влияет на план запроса. И вот здесь появляется bson.D: логические операторы — это операторы сервера, а массив условий — упорядоченная структура, и драйвер ждёт, что порядок сохранён. Мера жёсткости у v2 показательная: если передать unordered-карту туда, где порядок значим — например, в сортировку через options.Find().SetSort(), — драйвер отклонит аргумент ошибкой ErrMapForOrderedArgument ещё на клиенте. Фильтры верхнего уровня остаются территорией bson.M, но всё, что внутри $or и $and, привычнее писать через bson.D: визуально совпадает с документацией сервера и не вызывает вопросов при чтении. Полный разбор $regex для поиска по подстроке и комбинаций логических операторов — четырнадцатый урок.

Два условия, вокруг которых накопилось больше всего недоумений. Первое — $exists: он проверяет наличие поля в документе, и это не то же самое, что проверка на nil. Запрос bson.M{"phone": bson.M{"$exists": false}} найдёт документы, у которых поля phone нет вообще; а фильтр bson.M{"phone": nil} матчит и отсутствие поля, и поле со значением null — null в MongoDB означает «поле есть, значения нет», и равенство null специально расширено на пропущенные поля. Для мягкого удаления разница принципиальна: deleted_at отсутствует у живых записей и равна null — у «обнулённых» вручную; выбирайте семантику осознанно, мы вернёмся к ней в уроке про удаление. Второе тонкое место — типы в сравнениях: $gt по числовому полю сравнивает числа с числами, но документ, в котором цена по случайности записана строкой "1000", в диапазон не попадёт и ошибки не вызовет; $type в таких запросах вычисляет предателей. Это плата за схему без валидации — и аргумент за валидатор коллекции, до которого дойдём в двадцать втором уроке. Практика для отладки: сомневаетесь, почему документ не матчился, — воспроизведите фильтр в mongosh и сравните типы через typeof; расхождение BSON-типов всплывает быстрее, чем любую логику перечитывать.

Недооценённая выгода единого языка условий: фильтры не обслуживают только чтение. UpdateOne, UpdateMany, DeleteOne и DeleteMany принимают ровно тот же документ-условие, что и Find: неявный AND, операторы сравнения, $in и $or — всё работает в операциях записи без единого изменения. Практически это значит, что трудозатраты окупаются дважды: собрал и отладил фильтр «просроченные сессии» для выборки — тот же документ завтра пойдёт в UpdateMany, чтобы пометить их истёкшими, и в DeleteMany, чтобы почистить. Есть и нюансы. В операциях записи фильтр работает по тем же правилам типов и null-семантики, поэтому осторожность с {"поле": nil} важна вдвойне: под такой фильтр попадёт и отсутствие поля, и обновление затронет неожиданный документ. Составные условия в записи проверяются тем же CountDocuments до вызова: сначала посчитали, сколько документов ответит фильтру, потом отправили обновление — дешёвая страховка от пакетной операции по не тому множеству. И последнее: записи — территория уникальных индексов и валидаторов, о которых поговорим в семнадцатом и двадцать втором уроках; фильтр может быть сколь угодно хитрым, но быстрым его делает индекс, а безопасным — схема.