Условия Where и операторы — строковые, структурные, IN, LIKE, диапазоны

Основная форма — строковая: db.Where("status = ?", "todo"). Внутри метода Where(query interface{}, args ...interface{}) из chainable_api.go такая пара уходит в Statement.BuildCondition, который видит строку с вопросительным знаком и заворачивает её в clause.Expr — фрагмент SQL плюс список аргументов. При сборке запроса каждый ? заменяется плейсхолдером диалекта ($1 на PostgreSQL, ? на SQLite и MySQL), а значение едет в драйвер отдельно от текста команды. Оператор — любой SQL-ный: = и <> для неравенства, >, >=, <, <= для сравнений, AND и OR прямо внутри строки. Есть и короткая форма без плейсхолдера: db.Where("status", "doing") — строка без пробелов и с единственным аргументом превращается в равенство status = 'doing'. Строка условия — это сырой SQL: GORM не разбирает её на части, он лишь подставляет значения вместо ?. Отсюда два следствия: свобода (любой оператор и выражение, которые поймёт база) и ответственность — с неё и начнём.

Страница Security в документации GORM формулирует правило одной фразой: библиотека строит SQL через аргументные плейсхолдеры database/sql, которые автоматически экранируют значения — так SQL-инъекция отсекается на корню. Пользовательский ввод должен быть только аргументом: db.Where("name = ?", userInput) безопасен, даже если в userInput сидит «jinzhu;drop table users;» — драйвер отвезёт эту строку как значение, и база будет искать имя с точкой с запятой, а не исполнять её. Уязвимость появляется ровно в момент, когда ввод попадает в сам текст условия: db.Where(fmt.Sprintf("name = %v", userInput)) — вот это уже инъекция, потому что Sprintf вклеил строку в SQL до того, как её увидел драйвер. Кавычка внутри ввода закрыла строковый литерал — и хвост исполнился кодом. Плейсхолдеры — это не стиль и не вкусовщина, это граница между данными и кодом; всякий раз, когда соблазн склеить условие строкой «просто чтобы быстрее», вспоминайте этот абзац.

Вторая форма — структурная: db.Where(&TodoItem{Status: "todo"}).Find(&todos). BuildCondition разбирает структуру по схеме модели и на каждое ненулевое поле строит равенство: status = 'todo'. Удобство очевидно — колонки подставлены по схеме, опечатка в имени колонки ловится компилятором. Но у формы есть жёсткое правило, уже показанное в шестом уроке как ловушка: нулевые поля игнорируются. В Go «пустое» поле неотличимо от «не заполнял»: ноль, пустая строка, false — это zero values, и BuildCondition пропускает их через проверку isZero. Поэтому db.Where(&TodoItem{Priority: 0}) не даст WHERE priority = 0 — условие окажется пустым, и Find молча вернёт всю таблицу. Шестой урок обещал объяснить причину и дать второй фикс — вот они. Причина: структурные условия собираются только из ненулевых полей, ноль неотличим от «не заполнил». Первый фикс — карта: db.Where(map[string]interface{}{"priority": 0}) честно включает ноль, потому что карта не знает, что такое «пусто». Второй фикс — второй аргумент Where с перечнем полей, отдельный раздел ниже. Бонус формы: голый срез ключей как условие — db.Where([]uint{2, 4}) — разворачивается в WHERE id IN (2,4), это сахар над первичным ключом.

Официальное имя приёма — Specify Struct search fields: передавая после структуры перечень полей, вы делаете сразу две вещи. Первая — белый список: в условие едут только перечисленные поля, остальные выпадают, даже если заполнены. Вторая — форс нулей: перечисленное поле едет в условие, даже если его значение нулевое. Документированный пример: db.Where(&User{Name: "jinzhu"}, "name", "Age") даст WHERE name = 'jinzhu' AND age = 0 — Age нулевой, но упомянут, поэтому включён. Имена в перечне можно смешивать: GORM сверяет каждый аргумент и с именем колонки (name), и с Go-именем поля (Age). Обратная сторона белого списка — рестрикт: всё, что не перечислили, игнорируется. Структура с пятью заполненными полями и перечнем из одного поля даст условие ровно по одному полю — забытая позиция в списке молча исчезает из WHERE. Приём стоит держать для точечных случаев «нужен ноль» и для явной фиксации состава условия; как замена обычной структурной форме он слишком коварен.

Третий кит — оператор IN: заменить лес OR-равенств одним условием со списком. Каноническая форма из документации — db.Where("status IN ?", []string{"todo", "doing"}): после IN идёт плейсхолдер, а значение — срез. При сборке Statement.AddVar разворачивает срез в скобки с bind-переменными — получается WHERE status IN ('todo','doing'), где каждый элемент списка по-прежнему едет экранированным аргументом. Круглые скобки в строке — форма "status IN (?)" — тоже допустимы: GORM поймёт, что скобки уже открыты, и не добавит вторые. Сращивать список в строку через strings.Join или Sprintf не нужно никогда: это и инъекция, если элементы от пользователя, и лишняя работа — срез GORM развернёт сам. Поведение на пустом срезе стоит знать наизусть: пустой срез печатается как IN (NULL), что ложно для любой строки — вернётся ноль записей и ни одной ошибки. Зеркальный оператор NOT IN пишется той же строкой ("status NOT IN ?") или через Not с картой, в которой лежит срез.

Для поиска по подстроке SQL даёт LIKE с двумя спецсимволами: % — сколько угодно любых символов (в том числе ноль), _ — ровно один. Шаблон — это значение, а не часть условия: db.Where("title LIKE ?", "%хлеб%") — проценты сидят в аргументе, и их можно склеивать в Go: "%" + q + "%" безопасно, потому что склейка происходит над значением, которое драйвер потом экранирует (а вот % и _, пришедшие от пользователя, стоит вырезать или экранировать, если они не должны быть подстановками). С регистром всё зависит от диалекта, и здесь GORM не помощник — он передаёт текст условия базе как есть. PostgreSQL: LIKE регистрозависим, для поиска без учёта регистра у диалекта есть собственное расширение ILIKE — db.Where("title ILIKE ?", "%купить%") найдёт и «Купить хлеб». MySQL: при дефолтных коллациях *_ci LIKE регистронезависим сам по себе. SQLite: LIKE не различает регистр для ASCII-букв. Переносимый вариант руками — lower(title) LIKE lower(?), но функцию по колонке может лишить индекса — об этом разговор восемнадцатого урока.

Диапазонных операторов немного, и все — из SQL: >, >=, <, <= и BETWEEN ? AND ? с включительными границами. Время фильтруется теми же формами: db.Where("created_at > ?", weekAgo) — и плейсхолдер примет time.Time, драйвер сам переведёт его в таймстамп. Смысловая связка с chaining-ловушкой шестого урока: несколько Where в одной цепочке склеиваются AND — клозы сливаются в один WHERE по мере вызовов (MergeClause дописывает выражения в порядке вызова). Порядок вызовов отражается в SQL-следе, но на смысл чистых AND-условий не влияет — «A AND B» то же самое, что «B AND A»; влияет он только тогда, когда в цепочке появляется Or, о котором ниже. Напоминание одной фразой: инстанс после цепочки хранит уже добавленные условия — сохранить его в переменную можно только через Session(&gorm.Session{}), как показывал шестой урок. И ещё одна фраза на память: если в модели есть поле gorm.DeletedAt, GORM сам допишет к каждому WHERE условие deleted_at IS NULL — мягкое удаление молча сужает всякую выборку, детали девятого урока.

Метод Or добавляет к WHERE OR-группу: db.Where("role = ?", "admin").Or("role = ?", "super_admin") даст WHERE role = 'admin' OR role = 'super_admin'. Опасность в том, что склейка выражений плоская: db.Where("done = ?", false).Where("priority >= ?", 2).Or("status = ?", "doing") соберёт строку done = false AND priority >= 2 OR status = 'doing' — а по приоритету операторов SQL это (done = false AND priority >= 2) OR status = 'doing'. Автор цепочки почти всегда хотел иначе: «открытые с высоким приоритетом, плюс всё, что в работе». Вывод: появился Or в цепочке — смотрите след и думайте скобками. Помощь есть: если условие с AND написано одной строкой, GORM сам обернёт его в скобки — db.Where("done = ? AND priority >= ?", false, 2).Or("status = ?", "doing") даст уже (done = false AND priority >= 2) OR status = 'doing'. Для сложных случаев документация предлагает Group Conditions — вложенные db.Where, которые строят настоящие скобки; это территория продвинутой части курса. Not работает зеркально Where: строка получит NOT перед условием, срез в карте превратится в NOT IN, а структурное условие превратит каждое равенство в <>. И да, их строки — такой же сырой SQL с теми же правилами инъекционной гигиены.

Условия gorm закрыты: три формы условия, плейсхолдеры и гигиена против SQL-инъекции, IN с его нулевым срезом, LIKE и ILIKE, диапазоны, Or и Not — это фундамент, на котором стоят все остальные выборки курса: и фильтры пагинации, и мягкое удаление, и связи. Восьмой урок применит те же условия к записи — обновления Update и Updates принимают WHERE ровно в тех формах, которые вы только что разобрали; текстом говорим заранее, ссылки не даём: урок ещё не написан. Если хочется освежить, откуда взялись пять задач и их SQL-следы, вернитесь к пятому уроку про Create; механику чтения и ловушку chaining — в шестом уроке; полный план из 25 уроков — на странице курса. Домашка ниже собирает весь арсенал в один скрипт — и одну намеренную инъекцию для наглядности.