А кто-нибудь ещё решал эту задачу из Яндекса?
https://ru.stackoverflow.com/questions/1046528/%d0%a7%d0%b5%d1%82%d0%bd%d0%be%d1%81%d1%82%d1%8c-%d1%81%d0%be%d1%81%d0%b5%d0%b4%d0%b5%d0%b9

Добрый день,

помогите, пожалуйста, разобраться с вопросом. Пилим с коллегой проект, я фронт, коллега бэк, на бэке Java, Spring, Hibernate, сериализация объектов. Есть 2 ручки - создание и редактирование сущности, при создании поле name обязательное, при редактировании нет (даже в форме такого поля нет). Однако при редактировании от меня требуется также присылать это поле name (вообще говоря весь объект, с измененными полями, якобы для сериализации и отправки запроса в базу необходимо иметь весь объект). Мне удобнее присылать только измененные поля. Соответственно вопрос: как должно быть сделано правильно, необходимо присылать весь измененный объект или только то, что изменилось? Как быть если поля большие или их много? Возможно это какой-то паттерн проектирования, что почитать на эту тему? Спасибо.

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

Привет, это partial update.
Ну и на создание и update отдельный класс.
Если коротко
Entity это доменная модель
EntityDto то, то что возвращаем
EntityForm то, что принимаем

По partial update:
https://tools.ietf.org/html/rfc6902
https://www.baeldung.com/http-put-patch-difference-spring

Спасибо большое за ответы. Подскажите пожалуйста, а какова более распространенная, или best practice в данном вопросе? Делают put  и patch запросы, или не заморачиваются, и делают только put (или вообще post)? Мне кажется patch довольно редко встречается?

"можно" то всё, но как минимум PUT

да PATCH редко, но так же обратно противоположно как POST для UPDATE

Добрый вечер! Нужна помощь, пытаюсь вернуть из метода с аннотацией @Async boolean, но в процессе выполнения меня перекидывает в org.springframework.aop.interceptor, где один из методов почему то возвращает null. Что за беда такая?

потому что метод с такой аннотацией должен возвращать Future/CompletableFuture

пример каноничный

спасибо

У меня или на фото ?

На фото

Если на фронте использовать RFC 6902, тогда можно говорить о лучших практиках.
Это целостный подход, но может быть дороже и для фронта или для производительности работы с данными в бэк (если обновления будут высоконагруженными) . По сути протокол обновления, в бэк сущность сначала ищется целиком, применяется патч + валидации, затем сущность целиком сохраняется - консистентность сущности не нарушается.
https://www.baeldung.com/spring-rest-json-patch
или
https://cassiomolin.com/2019/06/10/using-http-patch-in-spring/

Как компромисный вариант, в REST  сервисе (HTTP PATCH) возможно принимать json в Map, как id + список полей для обновления с новыми значениями. На слоях ниже,  какими нибудь ModelMapper, MapStruct, Orika, Dozer или JMapper мэпить Map из модели api на модель данных, если потребуется.
И уже на слое данных реализовывать протокол обновлений - нужен какой то признак обновления полей, поэтому обычные Entity от PUT метода не пойдут. Проблема с JPARepository (Spring Data JPA)  в том, что для обновления нужно сделать отдельный запрос всей сущности, обновить поля и потом уйдет запрос на обновление всей сущности - хороший подход когда важна консистентность, излишний, когда важней количество запросов при обновлении. Можно делать гибче, на Jdbc Template, но и работ больше. Зато можно обойтись только одним запросом update только для измененных полей. Map можно мэпить на полные Entyty как то так, например для проверки типизации полей и консистентности связанных значений. Но, если необходимо генерировать минимальные обновления на уровне JDBC, список обновленных полей нужно держать отдельно, либо в особых полях сущностей.
Этот подход может усложнить код и отладку, если будет содержать частные технические решения низкого качества - стандартов тут как таковых нет. Обновления отдельных полей одной сущности разными пользователями АПИ, без необходимой валидации,  могут привести к неконсистентному состоянию сущности.

Всем привет. Подскажите пожалуйста. Если я буду заполнять бд в бине создания datasource - я гарантирую что никто до заполнения БД не воспользуется базой.

@Bean
public BalancedClickhouseDataSource clickHouseDataSource() {
 ClickHouseConfig clickHouseConfig = new ClickHouseConfig(environment);
 BalancedClickhouseDataSource dataSource = clickHouseConfig.configure();
 DatabasePopulatorUtils.execute(createDatabasePopulator(), dataSource);
 return dataSource;
}

Но это говорят странно заполнять БД в бине создания datasource. Как гарантировать что никто этим не воспользуется, если создать отдельный бин. Большое спасибо.

Повесь заполнение на событие контекста, типа ApplicationOnReady или типа того.

@EventListener(ApplicationReadyEvent.class) public void initDataBase() {

Понял, нужно воспользоваться DatasourceInitializer и ему передать популятор