Обновление и Upsert

Обновление в ent — это отдельный сгенерированный билдер, а не переклейка флагов на query: в blog/ent/user_update.go живут два строения. UserUpdate — массовая форма: client.User.Update() возвращает её без аргументов, Where принимает предикаты, Save отвечает парой (n int, err) — числом затронутых строк. UserUpdateOne — точечная форма: client.User.UpdateOneID(id) или UpdateOne(u) по готовой сущности; Where у неё нет — ключ и есть условие, а Save возвращает (*User, error). Это главный разворот ent update: выбор формы — выбор контракта возврата, и перепутать их не даст компилятор, потому что типы результата разные. Обе формы собирают мутацию одинаково: Set-методы копятся в поле UserMutation, и исполняется всё только на Save — до него билдер безопасно передаётся между функциями, клонируется и дополняется. Забудете Where в массовой форме — не будет ни ошибки, ни предупреждения: WHERE просто не сгенерируется, и UPDATE перепишет всю таблицу. ent не страхует от широких обновлений — это осознанный контракт SQL, и единственная страховка здесь ваша: сначала предикат, потом Set, и ни строкой иначе. Если вы искали по запросу ent update или «ent обновление записи» — запомните эту вилку первой: по id с возвратом строки, по условию с возвратом числа.

Откроем user_update.go и посмотрим, что делает SetName: он пишет значение в m.name и помечает имя как изменённое — u.mutation.SetName(s). Всё остальное — работа Save: сгенерированный код собирает список изменённых полей из мутации, прогоняет их через валидаторы схемы и только затем строит SQL. Это значит, что валидация из третьего урока работает и на обновлении: MaxLen, Positive, NotEmpty — те же проверки, те же ValidationError до похода в базу. Правило старых значений стоит проговорить явно: SetX всегда перезаписывает поле целиком, независимо от того, что лежало в колонке, и ent не читает старое значение, чтобы «слить» его с новым — обновление это не патч в JavaScript-смысле, а замена. Отдельная магия — поля с UpdateDefault из третьего урока: если у вас в схеме updated_at объявлен с UpdateDefault(time.Now), ent сам добавит его в UPDATE при каждом сохранении, и вы не увидите этого ни в мутации, ни в списке изменённых полей — генератор вставляет дефолт на этапе сборки стейтмента. Побочный эффект той же механики: поля с Immutable из третьего урока в update-билдере отсутствуют как класс — Set-мутатора для них не сгенерировано, и компилятор не даст «случайно» переписать email-ключ или дату создания. Схема дисциплинирует запись ещё до базы.

Форма Update().Where().SetX().Save(ctx) — рабочая лошадь миграций, административных скриптов и «пометить всех прочитанными». Её контракт: Save возвращает n — число строк, которые база сообщила как затронутые, — и никогда не возвращает сущности: строки не прочитаны, а переписаны на месте. Из этого следуют три привычки. Первая: n = 0 — не ошибка, а данные «под условие никто не подошёл»; обрабатывайте как нормальный исход, а не как сбой. Вторая: после массового обновления в памяти приложения лежат устаревшие объекты — если страница должна показать новое состояние, перечитайте выборку Query-ем из девятого урока или возвращайте клиенту n, а не данные. Третья — про ответственность: WHERE без ограничений или забытый вовсе переписывает таблицу целиком, и ent оставляет это на совести автора. Практическая страховка — тестировать предикат сначала чтением: тот же Where на Query().Count(ctx) покажет, сколько строк «в зоне поражения», и уже потом тот же предикат уезжает в Update. Дорогие вычисления в SET — выражения, подзапросы — ent прячет за sql.Expr и Modify из седьмого урока, но в девяноста процентах случаев хватает Set-мутаторов и семьи Add/Clear. Массовая форма — это SQL-мышление: одна команда, один поход, число как отчёт.

Откуда берётся *User из UpdateOneID, если UPDATE в SQL традиционно не возвращает строк? Сгенерированный Save строит UPDATE с клаузой RETURNING на диалектах, которые умеют возвращать — PostgreSQL и современные SQLite, — и сканирует результат прямо в структуру User. Там, где RETURNING нет, ent делает честную связку: UPDATE, затем SELECT по тому же первичному ключу — два похода, но один вызов API. Для вас разницы нет ни в типах, ни в порядке проверки ошибок, есть разница в SQL-следе, и вы увидите её в логе драйвера. Следствия практические. Первое: u.UpdatedAt и другие поля с UpdateDefault в возвращённой сущности уже свежие — не нужно перечитывать, чтобы узнать время изменения. Второе: рёбра возвращённой сущности пусты — Edges.Groups будет nil, потому что UPDATE не возит соседей; захотите граф — With-вызовы из одиннадцатого урока на отдельном Query. Третье: ExecX и SaveX — паникующие близнецы Save — существуют и здесь, но в сервисном коде держитесь ошибки: потеря пользователя между проверкой и записью — нормальный параллельный мир, а не исключительный случай. И четвёртое: массовая форма RETURNING не использует в принципе — ей нечего сканировать, её отчёт уже описан числом n.

Самая коварная ошибка обновления — счётчик через чтение. Классический сценарий: прочитали пользователя, прибавили к age единицу в Go, записали SetAge(u.Age + 1). Между чтением и записью другой воркер успел сделать то же самое — и одна из двух единиц исчезла: оба UPDATE записали значение, вычисленное из одного и того же старого. AddAge(1) решает это на уровне SQL: в SET уезжает выражение age = age + 1, а не литерал — база применяет его атомарно к текущему значению строки, и сколько бы воркеров ни сходилось, каждая единица доезжает. Тот же принцип обслуживает лайки, балансы, номера ревизий и денормализованный счётчик posts_count из двенадцатого урока: поддерживать его надо Add-мутаторами и в хуках, а не связкой «прочитал-пересчитал». Оговорка честности: атомарность выражения не отменяет вопросов конкурентности вокруг других полей той же строки — если операция «прибавить и тут же прочитать результат» должна быть строго согласованной, это территория транзакций, до которых мы дойдём в шестнадцатом уроке. А если валидация схемы требует, чтобы возраст оставался неотрицательным, — проверяйте условие до Add или в хуке, потому что валидаторы ent видят прибавляемое число, а не результат выражения в базе.

Восьмой урок разобрал upsert на одиночной вставке: OnConflict на create-билдере, смена типа цепочки на UserUpsertOne, UpdateNewValues, Ignore, DoNothing, свой SET через Update(func(u ent.UserUpsert)) и возврат id через ID(ctx). Здесь закроем то, что осталось за кадром, — bulk-upsert: пачка строк одним INSERT-ом с общей оговоркой ON CONFLICT. Билдер CreateBulk из восьмого урока сам не умеет конфликтовать — но у него есть тот же OnConflict, и после него цепочка превращается в bulk-версию upsert: один стейтмент «вставь эти пять, а по конфликту на email обнови». Флаг sql/upsert включался ещё в седьмом уроке — проверьте features перед go generate, иначе метода просто не будет. Семантика такая же, как у одиночной: UpdateNewValues берёт mutable-поля из вставки, Immutable-поля вроде created_at не переписываются, а Update с UserUpsert позволяет свой SET поверх — например, прибавить возраст инкрементом к существующему значению. Полезно помнить и про упор MySQL: цель конфликта ему не нужна (ON DUPLICATE KEY не принимает колонок), PostgreSQL без цели откажется — это было в predict восьмого урока. Upsert ent — единственный штатный способ «синхронизации каталога», когда клиент присылает полный список сущностей, а база должна заменить состояние без дубликатов и без двух фаз.

Вы умеете менять данные обеими формами: точечная UpdateOneID возвращает обновлённую сущность с свежим updated_at, массовая Update().Where() отвечает числом и страхуется прицелом; Add даёт атомарные инкременты, Clear и SetNillable наводят порядок в Optional-полях четвёртого урока, а bulk-upsert довёл до конца тему восьмого. Оставшийся жест — прощание: двенадцатый урок закрыл чтение, тринадцатый — запись, а четырнадцатый урок 14-delete разберёт удаление во всех видах: DeleteOneID и Delete с предикатами, счёт удалённых строк, каскадное поведение рёбер из пятого урока и мягкое удаление своими руками. До встречи с ним — домашнее задание: переведите PATCH-обработчик из шаблона «Get, потом Update» на UpdateOneID и сравните число запросов в логе. Полный план из 25 уроков — на странице курса, каталог предикатов для Where — в десятом уроке, страницы и сортировка для списков — в двенадцатом.