$and, $or, $regex: сложные фильтры

Фильтр с несколькими ключами — уже конъюнкция: bson.M{"status": "active", "stock": bson.M{"$gt": 0}} находит документы, где статус активен и остаток положителен. Это неявный AND, и он покрывает большинство запросов, пока условия лежат на разных полях. Явный $and нужен в двух случаях. Первый: одно поле должно удовлетворить нескольким условиям, которые не помещаются в один операторный документ — два диапазона с границами «строго больше» и «не больше» записываются как {"$and": [{"qty": {"$gt": 5}}, {"qty": {"$lte": 20}}]}. Второй: нужно скомбинировать две $or-группы — об этом отдельный блок ниже. Записывается $and массивом условий: bson.D{{Key: "$and", Value: []bson.M{...}}}; порядок элементов массива сервер сохраняет, поэтому для сложных конъюнкций берут bson.D, а не карту — карта и здесь рискует перезаписью ключей. Внутри массива каждый элемент — обычный фильтр: равенства, операторы, вложенные $or — всё то же самое на один уровень глубже. Явный $and с единственным условием избыточен: такое условие спокойно живёт в одной карте рядом с другими, и оператор оправдан, только когда без него не собрать.

$or принимает массив условий и находит документы, подходящие хотя бы под одно: поиск по названию или описанию записывается bson.M{"$or": []bson.M{{"name": ...}, {"description": ...}}}. В Go-коде mongo or filter чаще всего собирается именно срезом bson.M — каждый элемент самостоятельный фильтр со своими операторами. Ловушка подстерегает на уровне языка: задача «активные или отложенные, но не архивные» выглядит как два ключа $or в одной карте, но карта в Go хранит ключ один раз — второй $or перезапишет первый ещё при сборке литерала, без ошибки компиляции и без ошибки сервера. Половина условий исчезает молча, и фильтр находит не то, что задумано. Решение — упаковать обе группы в $and: bson.D{{Key: "$and", Value: []bson.M{{"$or": ...}, {"archived": ...}}}} — каждый элемент массива живёт своей жизнью. Вложенность ограничена только здравым смыслом: $or внутри $and внутри $or читается уже с трудом, и это сигнал вынести сборку фильтра в именованную функцию с комментариями. Рядом стоит зеркальный оператор $nor: он находит документы, не подходящие ни под одно условие из массива, — «не архив и не черновик» иногда читается через $nor из двух равенств, хотя чаще та же запись живёт в $nin со списком значений.

Оператор $regex запускает на сервере регэксп: bson.M{"name": bson.M{"$regex": "^клавиатура", "$options": "i"}} находит имена, начинающиеся на «клавиатура», в любом регистре. Паттерн — обычная строка, опции идут отдельным ключом $options: i снимает регистр, m включает якоря по строкам, x разрешает пробелы в шаблоне. Вторая форма записи — тип bson.Regex из пакета bson: bson.Regex{Pattern: "^клавиатура", Options: "i"} вставляется прямо как значение фильтра, и кодек соберёт BSON-тип регэкспа; в v1 этот тип назывался primitive.Regex. Для regex поиска mongodb-сервер компилирует паттерн в свой движок, и синтаксис там PCRE-подобный, а не Go-шный: look-ahead в нём есть, а именованные классы пишутся по-другому — паттерн пишется для сервера, а не для пакета regexp. Цена операции зависит от якоря: паттерн с префиксом ^буквы может опираться на индекс и перебирать только его начало; паттерн без якоря заставляет сервер проверять каждое значение каждого документа коллекции. Опции парсятся однобуквенные: i снимает регистр, m включает якоря по строкам, s делает точку совпадающей с переводом строки, x разрешает пробелы в шаблоне, u включает юникод-таблицы. Самая частая — i, и её же чаще всего добавляют без нужды: регистр важен для артикулов и кодов.

Два регэксп-движка в одном проекте — постоянный источник путаницы, поэтому разложим грани. Паттерн в $regex исполняет сервер MongoDB: синтаксис близок к PCRE — есть look-ahead и look-behind, классы \d и \w, а флаги живут в $options. Пакет regexp в Go исполняет RE2: look-around в нём принципиально отсутствует, зато он линеен по времени и не подвержен катастрофическому бэктрекингу. Из Go в фильтр паттерн уезжает строкой, и его пишут под серверный движок; Go-regexp нужны только для проверки на клиенте, если она вообще нужна. Вторая граница — экранирование: пользовательский ввод почти всегда содержит спецсимволы, и regexp.QuoteMeta превращает их в литералы; без этого скобка или звёздочка в запросе меняют смысл паттерна. Третья граница — сами флаги: опции сервера однобуквенные, i для регистра — самое частое; вместе с якорем ^ префиксный поиск по индексу остаётся быстрым, всё остальное — платно. Паттерн — обычная строка, поэтому его удобно отлаживать в mongosh тем же запросом: db.coll.find({ name: { $regex: "...", $options: "i" } }) — увиденный там состав выборки совпадёт с выдачей драйвера байт в байт.

Соберём три запроса, которые встречаются почти в каждом сервисе. Поиск по любому из полей: $or со срезом из name и description, каждый элемент — свой $regex с QuoteMeta-вводом и опцией i; итог — «фраза встречается где угодно из двух мест». Исключение неактуального: {"archived": {"$ne": true}} и {"status": {"$nin": ["draft", "deleted"]}} рядом в неявном AND — карта справится, ключи разные. Комбо с диапазоном: цена между границами через $gte и $lte в одном вложенном документе, статус через $in со списком допустимых — и всё это внутри $and с $or-группой для поиска. Общий приём у всех трёх — сборка через именованную функцию, возвращающую bson.D или bson.M: панель с пятью необязательными полями в виде одного литерала не читается, а функция с append по условию — читается и тестируется. Фильтры из этих примеров уходят в Find и Aggregate одинаково: синтаксис условий общий, агрегации лишь оборачивают его в этап $match. Отдельная мелочь, о которой стоит знать заранее: сравнить два поля документа операторами запроса нельзя — $gte сравнивает поле с константой. Для «остаток больше зарезервировано» есть $expr: {"$expr": {"$gt": ["$stock", "$reserved"]}} запускает агрегационное выражение прямо в фильтре — это мост к конвейерам пятнадцатого урока.