Обновление записей — Update, Updates, UpdateColumn, gorm.Expr и блокировки

Сигнатура из finisher_api.go лаконична: func (db DB) Update(column string, value interface{}) (tx DB). Внутри метод кладёт в Statement.Dest карту map[string]interface{}{column: value} и запускает цепочку колбэков Update — отсюда все поведения, о которых пойдёт речь: WHERE из модели, автоправка updated_at, защита от глобальных правок. WHERE берётся из двух мест, и полезно понимать, какое сработало. Первое — первичный ключ структуры в Model(&task): после чтения из базы task.ID = 3, и при обновлении GORM сам превратит ключ в условие WHERE id = 3 — механика ConvertToAssignments в callbacks/update.go выносит первичные ключи обновляемой модели из SET в WHERE. Второе — явный Where: db.Model(&TodoItem{}).Where("status = ?", "todo").Update(...) — формы условий ровно те, что разобраны седьмым уроком, ничего нового придумывать не нужно. Если модель в Model без ключа и Where нет — сработает защита ErrMissingWhereClause, ей посвящён отдельный раздел ниже. Кто ищет update gorm в поиске, хочет именно эту пару: Update по колонке плюс условие из Where. Одна колонка за вызов — как только полей становится два, дорога ведёт к Updates, следующему разделу.

Сигнатура соседа: func (db DB) Updates(values interface{}) (tx DB), а комментарий в finisher_api.go уточняет: values must be a struct or map — третьего не дано. Структура — продолжение знакомой истории: обновление собирается только из ненулевых полей, то же isZero-правило, что и в структурных условиях седьмого урока, работает и здесь. Задали Done: false — поле молча выпало из SET. Не ошибка, а самая дорогая тишина в CRUD: запрос выглядит успешным, значение не тронуто, заметите вы это по косвенным признакам. Зато каждая ненулевая колонка типизирована компилятором: опечатка в имени поля ловится на этапе сборки, а не в продакшене. Карта — противоположный характер: едут все ключи, включая нули, потому что карта не умеет отличать «пусто» от «не заполнял»; это путь к честным done = false и priority = 0. Две детали механики из callbacks/update.go. Первая: ключи карты GORM сортирует — sort.Strings над списком ключей, поэтому колонки в SET идут по алфавиту и SQL-след стабилен от запуска к запуску. Вторая: updated_at дописывается сам, если его нет среди ключей карты или полей структуры — разговор о времени ниже, в разделе про UpdateColumn. Как выбирать: типобезопасные частичные правки — структурой; нулевые значения и динамический состав из запросов API — картой.

Оба метода в обновлении — про белый список колонок, и это зеркальное отражение Specify Struct search fields из седьмого урока: только вместо WHERE фильтруется SET. Select перечисляет, что ехать: перечисленное включается даже нулевым — единственный структурный способ записать ноль без карты. Select("*") берёт всю структуру как есть, с нулями, — способ «передать модель целиком». Omit вычёркивает колонку — тоже и со структурой, и с картой: так обновляют всё, кроме опасной колонки, скажем slug или version, случайная перезапись которых ломает данные. У приёма та же обратная сторона, что у условий: рестрикт. Забытая в Select колонка молча не поедет — запрос завершится успехом, а поле останется старым, и никакая ошибка об этом не скажет. Отсюда дисциплина: состав SET критичен — перечисляйте Select явно и смотрите SQL-след перед отправкой; пусть лучше лишнее уедет осознанно, чем нужное пропадёт молча.

У результата любого финишера есть result.RowsAffected, и для обновлений это главный ответ на вопрос «что произошло». UPDATE без совпадений — законная ситуация: задачу удалил другой пользователь, ключ остался от старого кеша, фильтр не совпал. GORM вернёт RowsAffected = 0 и Error = nil: не нашлось — не ошибка, в отличие от First с его ErrRecordNotFound из шестого урока. Отсюда две привычки. Первая: в API, который обещает клиенту конкретную запись, проверяйте «нашлась ли строка» — иначе пользователь получит успешный 200 OK при несуществующем id. Вторая: знать, что именно считает база. PostgreSQL возвращает все строки, затронутые UPDATE, даже если значения не изменились. MySQL по умолчанию считает только реально изменённые: SET priority = 2 на строке, где уже priority = 2, даст ноль. Драйвер go-sql-driver имеет параметр DSN clientFoundRows=true — он возвращает MySQL к поведению «найденных» строк. SQLite считает затронутые строки, как PostgreSQL: проверка запросом с неизменяющим SET это покажет за минуту. Для атомарных инкрементов и блокировок ниже RowsAffected == 0 станет точным признаком проигранной гонки.

В finisher_api.go рядом с Update живут два метода, отличающиеся одной строкой: tx.Statement.SkipHooks = true. UpdateColumn(column, value) — для одного поля, UpdateColumns(values) — для пачки, структура или карта. SkipHooks выключает сразу два слоя автоматики. Первый — хуки модели: BeforeSave и BeforeUpdate перед запросом, AfterSave и AfterUpdate после; служебная правка не должна дёргать бизнес-логику, которую вы повесили на модель. Второй — автоправка времени. У полей с меткой AutoUpdateTime (ваш UpdatedAt из схемы — time.Time поле размечается автоматически) каждый Update и Updates подменяют значение текущим временем: при структурном обновлении поле всегда пишется now, при обновлении картой — если ключа updated_at нет среди прочих; картой время можно и перезаписать явно, положив своё значение в ключ. UpdateColumn и UpdateColumns этого не делают: updated_at остаётся каким был. Смысл прозрачен: updated_at должен означать «пользователь тронул запись», а не «скрипт пересчитал счётчик». Учтите: защита от глобальных обновлений на них распространяется в полном объёме — WHERE нужен и здесь.

Классический баг конкурентности: два воркера поднимают приоритет одной задачи. Оба читают priority = 2, оба прибавляют единицу в Go, оба пишут 3 — одно повышение потеряно. Схема «прочитал — посчитал — записал» ломается всегда, когда между чтением и записью может вклиниться кто-то ещё, а может он почти всегда. gorm.Expr из gorm.go разрубает узел: func Expr(expr string, args ...interface{}) clause.Expr — выражение передаётся базе как значение, и SET priority = priority + 1 вычисляет СУБД в момент исполнения над актуальной строкой. Один запрос, никакого чтения, никакого окна для гонки. Аргументы Expr едут плейсхолдерами и экранируются драйвером — то же правило седьмого урока: переменные живут в аргументах, а не в строке выражения. Форма работает везде, где ждут значение: в Update, в карте Updates, в UpdateColumn и UpdateColumns. Внутри выражения — любой SQL, который поймёт ваш диалект: арифметика, функции, CASE. Переносимость выражения — забота ваша: GORM текст выражения не разбирает и не проверяет.

Инкремент закрыл арифметику, но правки бывают сложнее: два менеджера редактируют одну задачу в разных окнах, оба жмут «Сохранить» — чья версия переживёт, та и останется, вторая сгинет молча. Это потерянное обновление, и у него два канонических ответа. Первый — оптимистичная блокировка: к модели добавляется счётчик версий, читаем его вместе с данными, а при записи ставим двойное условие — ключ и та самая версия — и наращиваем счётчик атомарно через gorm.Expr. Кто-то успел раньше? Его запрос уже поднял версию, наше Where("version = ?") промахнулось, RowsAffected = 0 — и мы честно узнаём о конфликте вместо тихой порчи данных. Никаких блокировок СУБД не держит, отсюда имя «оптимистичная»: рассчитываем, что конфликтов мало, и проверяем постфактум. Поле добавить легко: Version int в структуру задачи — AutoMigrate из четвёртого урока добавит колонку сам. Схема хорошо ложится на веб: перечитать и повторить — штатный путь, а не авария; данные читаются без транзакций; конфликты редки, потому что разные клиенты правят разные записи. Держите её как дефолт, а пессимистичную из следующего раздела оставьте горячим строкам.

Второй ответ — пессимистичная блокировка: заблокировать строку до правки, чтобы конкурент даже не пытался. Рецепт: транзакция, внутри — чтение с клозом блокировки tx.Clauses(clause.Locking{Strength: "UPDATE"}).First(&task, 3), и SELECT уезжает в базу с хвостом FOR UPDATE: строка заблокирована до COMMIT или ROLLBACK, конкурентная транзакция с таким же FOR UPDATE повиснет на своём чтении и дождётся нашей. Клоз описан в clause/locking.go: поле Strength принимает константы LockingStrengthUpdate ("UPDATE") и LockingStrengthShare ("SHARE" — FOR SHARE, блокировка от изменений, но не от чтений), поле Options — LockingOptionsNoWait ("NOWAIT") и LockingOptionsSkipLocked ("SKIP LOCKED"): не ждать занятую строку, а сразу ошибиться или молча пропустить. Заметьте, что FOR UPDATE едет в SELECT: клоз FOR входит в сборку запроса на чтение, а правка потом делается обычным Update — блокирует чтение, а не запись. Транзакция не опция, а обязательное условие: без неё SELECT живёт в автокоммите и замок рассыпается сразу после чтения. Выбор между схемами прагматичен: короткие правки и редкие конфликты — оптимистичная; горячая строка, которую щупают все воркеры одновременно, — пессимистичная, чтобы конкуренция выстроилась в очередь, а не в бесконечные повторы.

CRUD почти собран: C из пятого урока, R из шестого и седьмого, U из этого — осталась D, и она интереснее, чем кажется. Девятый урок — Удаление и мягкое удаление: Delete по ключу и по условию, поле gorm.DeletedAt, из-за которого «удалённые» строки продолжают жить в таблице, Unscoped для настоящей чистки и даже восстановление; там же станет понятен deleted_at IS NULL, мелькавший в этом уроке одной фразой. Если нужно освежить формы условий, вернитесь к седьмому уроку про Where; чтение, First и ErrRecordNotFound — в шестом уроке; полный план из 25 уроков — на странице курса. Домашка ниже собирает все финишеры обновления и обе блокировки в один скрипт.