поле name1 всё равно сериализуется в dto в null ты ж вроде и так нулл хочешь?

Нет, присвоить null только тем полям, которые определены в json и не трогать остальные. Из дтошки присваивается энтити.

а чем (как) ты десериалиузешь

видимо это Георгий хоетл узнать

Джексоном

...

вот тогда ответ выше

мы прям все ток джексон используем тут чтоб джейсон выковыривать (дефолт либа как никак и других нет)

Джексоном

И да, совет тебе - задавай вопросы точнее

Тебе очень сильно повезло что у тебя стали выуживать нужную информацию, так бы просто проигнорировали

Спасибо за совет

ну и джейсон библиотек больше чем одна, тут в этом соль еще.

Десериализатор под конкретную сущность здесь не подойдёт, нужно разработать универсальный механизм апдейта полей базы

ААА

причем тут база

Из дтошки энтити апдейтится

Нет, присвоить null только тем полям, которые определены в json и не трогать остальные. Из дтошки присваивается энтити.

Вообще, погуглив (тоже крутой совет), люди пишут, что если поля нет в JSON, то джексон просто не будет вызывать сеттер на это поле. https://stackoverflow.com/a/19551195/6395606 https://github.com/FasterXML/jackson-datatype-jdk8/issues/2#issuecomment-389191907

вы точно уверены, что jackson скидывает ранее инициализированные поля на null?

Так дтошка чистая на входе. Параметр контроллера.

Так дтошка чистая на входе. Параметр контроллера.

так там изначально поля null?

Да

тогда в чем проблема?

Из ДТО апдейтится энтити. Проблема в том, что нужно апдейтить только те поля, которые в джейсоне явно указаны для зануления.

И не трогать остальные

Следующий совет - ты решил что проблема в этом и решать следует на этом уровне

Хибер?

Да, хибер

@DynamicUpdate

Поищи что это

Видел

Хотя...

Чем не устроило?

как же хочется реактивный jdbc...

Он генерит скуль только для тех полей, которые менялись. Но, если пришла дто с нулевыми полями, а нам нужно сбрасывать только те, которые в джейсоне указаны

Т.е., в идеальном случае, нужно, чтобы джейсон был своего рода запросом на апдейт таблицы

ну наконец-то

теперь понятно в чем проблема

у тебя в DTO нет информации о том, отсутсвовало это поле в JSON или присутствовало со значением null

Нет, это обычный POJO

в DTO в обеих случаях будет null

Нет, это обычный POJO

это понятно

в DTO в обеих случаях будет null

Да

как ты собираешься использовать в таком случае DTO для того чтоб доставить эту информацию до Entity?

Как вариант - в dto следить, какие сеттеры вызывал jackson при десериализации. И на этапе конвертации dto -> entity, проверять if(dto.isFieldSet()){ entity.field = dto.field; } Если в JSON пришел null, поле обнулится в entity. Если поля не было в JSON -> сеттер не вызван -> entity не будет затронута

как ты собираешься использовать в таком случае DTO для того чтоб доставить эту информацию до Entity?

По существующему алгоритму, в энтити только ненулевые поля присваиваются

Как вариант - в dto следить, какие сеттеры вызывал jackson при десериализации. И на этапе конвертации dto -> entity, проверять if(dto.isFieldSet()){ entity.field = dto.field; } Если в JSON пришел null, поле обнулится в entity. Если поля не было в JSON -> сеттер не вызван -> entity не будет затронута

Как можно проследить, вызван сеттер или нет?

в сеттере прямо

void setField(Integer value) { this.isFieldSet = true; this.field = value; }

Тогда следующий вопрос - как переопределить сеттер, если используется ломбок?

очевидно просто руками его написать

void setField(Integer value) { this.isFieldSet = true; this.field = value; }

Либо так public class Object { private Optional<Object> field = Optional.empty(); public void setField(Object o) { this.field = Optional.of(o); } } И потом проверять на if(isValueSet(field)) { entity.field = getValue(dto.field); } public <T> boolean isValueSet(Optional<T> o) { return o == null || o.isPresent(); } public <T> T getValue(Optional<T> o) { return o == null ? null : o.get() } Хотя я щас все это написал и как-то слишком получается... В голове это выглядело лучше

Предыдущий вариант предпочтительнее

Либо так public class Object { private Optional<Object> field = Optional.empty(); public void setField(Object o) { this.field = Optional.of(o); } } И потом проверять на if(isValueSet(field)) { entity.field = getValue(dto.field); } public <T> boolean isValueSet(Optional<T> o) { return o == null || o.isPresent(); } public <T> T getValue(Optional<T> o) { return o == null ? null : o.get() } Хотя я щас все это написал и как-то слишком получается... В голове это выглядело лучше

Не надо в аргументах опшионалы принимать

а джексон умеет работать с Optional?

Не знаю

Не надо в аргументах опшионалы принимать

почему?

И что это за дикая проверка на null ?

Но вещь все равно сложная..

почитай в вики про CRTP кстати, в с++ и c# это имеет большее практическое применение, из-за того, что там нет legacy-наследства, вынуждающего к type-erasure

Либо так public class Object { private Optional<Object> field = Optional.empty(); public void setField(Object o) { this.field = Optional.of(o); } } И потом проверять на if(isValueSet(field)) { entity.field = getValue(dto.field); } public <T> boolean isValueSet(Optional<T> o) { return o == null || o.isPresent(); } public <T> T getValue(Optional<T> o) { return o == null ? null : o.get() } Хотя я щас все это написал и как-то слишком получается... В голове это выглядело лучше

мне вариант с Optional больше нравится

почитай в вики про CRTP кстати, в с++ и c# это имеет большее практическое применение, из-за того, что там нет legacy-наследства, вынуждающего к type-erasure

Да, в философии приводят сравнение, там шаблоны штука более мощная

И что это за дикая проверка на null ?

Читай выше. 3 состояния: сеттер был вызыван и засетил null, сеттер не был вызыван (Optional.empty()), сеттер был вызван и поставлено какое-то значение

Читай выше. 3 состояния: сеттер был вызыван и засетил null, сеттер не был вызыван (Optional.empty()), сеттер был вызван и поставлено какое-то значение

4-state boolean )))

у групповых операций в CHM (search, reduce) есть какие-то преимущества, кроме использования fork/join?

ERROR: S client not available

Читай выше. 3 состояния: сеттер был вызыван и засетил null, сеттер не был вызыван (Optional.empty()), сеттер был вызван и поставлено какое-то значение

Чето какая-то хрень

Ты что-то делаешь не так

Ты что-то делаешь не так

@Andrsam слышал?

Например?

4-state boolean )))

помню здесь кто-то предлагал уже хранить в Optional<Boolean> 4 разных значения: null, empty, false, true

помню здесь кто-то предлагал уже хранить в Optional<Boolean> 4 разных значения: null, empty, false, true

вот же наркоман

Например использовать опшианалы в полях класса, в аргументах

Например использовать опшианалы в полях класса, в аргументах

Щас бы врываться в обсуждение и говорить что кто-то что-то делает не так, не прочитав изначальную проблему...

Например использовать опшианалы в полях класса, в аргументах

опшионалы нужны, чтоб избавиться от npe, нуллы там хранить не надо

Опшионалов в полях класса нет и не планируется

Щас бы врываться в обсуждение и говорить что кто-то что-то делает не так, не прочитав изначальную проблему...

Ну так посвяти в проблему :)

Ну так посвяти в проблему :)

так прочитай :)

Опшионалов в полях класса нет и не планируется

в аргументы функции не надо передавать их тоже, чтобы не было o == null || o.isPresent()

Идея с булевыми флагами мне очень понравилась, спасибо

Идея с булевыми флагами мне очень понравилась, спасибо

Переходи на сторону добра, у нас есть печеньки

Когда-нибудь ты уйдешь из проекта, а потом кому-то этот код поддерживать (хоть в жабадоке мотивацию напиши, почему так сделано)

Тоже верно

Не надо в аргументах опшионалы принимать

+++, с сериализацией у него проблемы

Из ДТО апдейтится энтити. Проблема в том, что нужно апдейтить только те поля, которые в джейсоне явно указаны для зануления.

Тебя спасёт просто кастомный маппер - специальный класс, который принимает дто и отдаёт энтити и наоборот.

jackson используйте и все

там в одну строчку нулл-ы игнорируются

+++, с сериализацией у него проблемы

Какие?

Какие?

Иди детей воруй

а джексон умеет работать с Optional?

умеет https://github.com/FasterXML/jackson-modules-java8/tree/master/datatypes

Что ты тут забыл, сисярпист треклятый?

Я не помню с ним проблем, если честно.

там в одну строчку нулл-ы игнорируются

Да, либо в конфиге обжект маппера, либо аннотацией над классом.

Да и это довольно удобный способ показать что параметр или поле не обязательны

Иди детей воруй

Ты чего?

Проблема же была в том, что этот класс используется для проведения запросов в базу

И что не было понятно, что нужно обновлять при апдейте