имеют not null constraint. Я прописал условие ON CONFLICT ... что устанавливаю name = excluded.name (то есть я обновляю 1 поле из 11 и значение этого поля устанавливаю как "Test"), но мне выдает ошибку
ERROR: null value in column "description" of relation "user_saved_trip_recommendations" violates not-null constraint
Запрос
INSERT INTO user_saved_trip_recommendations (id, user_id, name) VALUES (11, 1, 'TextX') ON CONFLICT (id) DO UPDATE SET name = excluded.name;
Cтруктура таблицы user_saved_trip_recommendations
Table "public.user_saved_trip_recommendations"
Column | Type | Collation | Nullable | Default
------------------+------------------------+-----------+----------+-------------------------------------------------------------
id | bigint | | not null | nextval('user_saved_trip_recommendations_id_seq'::regclass)
user_id | bigint | | not null |
name | text | | not null |
description | text | | not null |
keypoints | json | | not null |
images | text[] | | not null |
dates | json | | not null |
country_name | character varying(128) | | not null |
country_iso_code | character varying(3) | | not null |
destination_code | character varying(4) | | not null |
lowest_price | numeric(12,2) | | |
Как правильно обновить 1 поле через insert into on conflict?
надо полагать, как-то так: INSERT INTO user_saved_trip_recommendations (id, user_id, name, description) VALUES (11, 1, 'TextX', 'DescX') ON CONFLICT (id) DO UPDATE SET name = excluded.name;
Так а мне не нужно обновлять description поле, только name
а вы его и не обновляете. только вставляете.
То есть можно фактически вместо description пустую строку как '' вставить главное чтоб это не было null и так с каждым not null полем?
да, будет работать (если там где-то в недрах не навешен ещё CONSTRAINT CHECK на то, что это пустая строка).
с каждым текстовым так можно поступить. с числовыми — уже нет. но вообще несколько странно: иметь CONSTRAINT NOT NULL на поле и хотеть туда вставить NULL или обойти это вставкой пустой строки. но тут уже сами решайте имхо. если это какой-то крупный проект, в котором вы не один, я бы перед тем как делать, чисто для облегчения (совести) спросил бы у коллег: "а ничего если я, делая [такую-то задачу], descriprion пустой укажу?"
Ну у меня изначальна была идея такова: чтоб postgres бил палкой по руках если пытаемся вставить неполноценно запись (ну например не вставить name поле, хотя оно обязательно). Потом появилось требование ещё и обновлять эти данные, я ж делаю это не через сырые sql запросы, а через программный api и для минимизации кода использую insert into on update stmt. Вот теперь я понимаю что походу усложнил себе жизнь и изначально не нужно было вешать на 10 ил 11 полей not null))
меня немного смущает то, что вы пытаетесь обновлять данные upsert'ом, а не update'ом. у меня складывается подспудное ощущение, что insert в вашем запросе вам только жизнь портит. если бы вы хоть раз упомянули про вставку данных — вопросов нет, но вы пишите про только обновление. но юзаете при этом upsert (insert into ... on conflict do update ...) вместо update.
Вам точно merge не нужен при 11 полях спокойно обрабатывайте исключения
Ну тут длинная история, если вкратце: исторически так сложилось, потому что все используют ORM (Gorm), а оно делает под капотом через upsert вставку/обновление с минимальным усилием по коду. Получается 1 метод для вставки/обновления объекта вместо 2х, нету сегрегации на CreateEntity/UpdateEntity)
Ну и пусть делает)
Вы ему констрейнтов навешайте он ругаться будет
В плане "обрабатывайте исключения" ?
Обсуждают сегодня