Optional и Nillable поля

NULL в SQL — это не «пусто», а «значения нет и не было»: биография не заполнена, срок не поставлен, ник ещё не выбран. У Go позиция другая: каждый тип имеет нулевое значение, которое нельзя отключить — 0 для чисел, false для bool, пустая строка, 1 января нулевого года для time.Time. Две картины мира сталкиваются в момент чтения строки из базы: драйвер database/sql достаёт колонку через обёртку sql.NullString с флагом Valid, а сгенерированный код ent переводит результат на язык структуры. Правило перевода короткое: у Nillable-полей NULL становится nil, у обычных — нулевым значением типа. Ту же задачу мы видели в уроке про sqlc типы: там nullable колонки превращаются в sql.NullString и pgtype с тем же флагом Valid — ent выбрал третий путь, указатели. Так себя вели и классические ORM: в вводном уроке GORM нулевые значения и «нет данных» путались в одном поле точно так же. Разница между «в базе NULL» и «в базе пустая строка» переживает это путешествие только при одной из стратегий — в этом весь сюжет урока.

Первая стратегия — та, по которой построено bio: field.String("bio").Optional().Nillable(). Optional снимает обязательность: SetBio можно не вызывать, Save не вернёт missing required field, а колонка становится nullable. Nillable меняет тип в сгенерированной структуре на *string: ent читает NULL и кладёт в Bio nil, читает значение — кладёт указатель на строку. Проверка u.Bio == nil — честный вопрос «в базе есть что-нибудь?», и ответ больше не подменяется пустой строкой.

Когда указатели эргономичны: для строк, времени и любых типов, где «пустота» — отдельное состояние со своим смыслом. Био, дата публикации, дата блокировки, токен — все они бывают «не заданы», и каждое из этих состояний нужно различать. Когда указатели избыточны: для счётчиков и bool, где нулевое значение редко несёт отдельный смысл, а разыменование *u.Bio захламляет код. Цена стратегии не нулевая и на границе API: nil-указатель требует решения, что отдавать клиенту — null, пустую строку или вовсе убрать поле из ответа. Этот выбор разберём на блоке про JSON.

Схема готова — смотрим, что ent сгенерировал для Optional-поля bio. Три рабочих метода. SetBio("...") записывает строку. SetNillableBio(p) принимает string и устроен внутри честно: if v != nil { SetBio(v) } — nil молча пропускается; формулировка документации ent так и звучит: «sets the field if the given value is not nil». ClearBio() помечает поле на очистку — Save отправит в базу NULL. Рядом есть ResetBio, но он не про базу: метод отменяет незавершённое изменение внутри мутации, значение в таблице он не трогает.

Теперь распределение по билдерам. У create-билдера ClearBio нет — при создании «не вызвал Set» уже означает NULL, чистить нечего. У update-билдеров — UserUpdate и UserUpdateOne — ClearBio есть и работает. Заметьте: SetNillableBio генерируется для любого Optional-поля, даже без Nillable — у website он тоже будет, с типом *string. А вот обязательным полям, включая role с Default, ни SetNillable, ни Clear не положены: колонка NOT NULL, там NULL не бывает.

Фильтр «найти пустые» упирается в особенность SQL: сравнение bio = NULL никогда не бывает истинным — неизвестность тянется и в равенство, и в неравенство, поэтому строка с NULL не пройдёт ни bio = NULL, ни bio <> NULL. У SQL есть отдельные операторы IS NULL и IS NOT NULL, а ent генерирует для каждого Optional-поля пару предикатов: user.BioIsNil() и user.BioNotNil(). В сгенерированном where.go за ними стоят sql.FieldIsNull и sql.FieldNotNull — прямой перевод IS NULL на язык билдера. Работают предикаты на уровне колонки, так что не важно, какая из двух стратегий у поля: BioIsNil найдёт и nil-указатель, и пустую строку, которой дублировали NULL. Цепочка client.User.Query().Where(user.BioIsNil()).Count(ctx) вернёт всех, кто био не заполнял. Обязательным полям предикаты не генерируются: у name NULL не бывает, и NameIsNil просто не существует.

Nillable умеет жить и без Optional — на обязательных полях. Сценарий: поле заполняется дефолтом, но при частичных выборках (о них — в будущих уроках про запросы) его может не быть в прочитанной строке. Тогда обычный time.Time честно покажет нулевую дату 0001-01-01T00:00:00Z — она же пробьётся в json.Marshal: в примере из документации ent пустая Task сериализуется как {"created_at":"0001-01-01T00:00:00Z"}. У Nillable-поля в той же ситуации nil: в коде «значения нет» видно, а с дефолтным тегом omitempty поле просто не попадёт в JSON. В прошлом уроке эта способность упоминалась одной строкой — теперь причина ясна: Nillable не про nullable колонку, а про честное представление «значения может не быть» в самом Go.