How to become an author
Search
Write a publication
Pull to refresh
2
Karma
0
Rating
Andriy Slobodyanyk @Slobodator

Java Developer

Send message
ProfileArticlesPostsNewsComments20
Spring Data JPA и Hibernate: ориентируемся на производительность. Часть 1

Я бы предложил для случаев, когда идёт микс из обращений к БД и внешним сервисам (читай -- медленное I/O), и мы переходим на ручное управление транзакциями, не стыдливо комментирировать аннотацию

//@Transactional
public void withExternalServiceCallAfter() {
	transactionTemplate.executeWithoutResult(transactionStatus -> {
    		System.out.println(personRepository.findAll());
	});

	externalService.externalCall();
}

... а смело вешать 

@Transactional(propagation = Propagation.NEVER)
public void withExternalServiceCallAfter() {...}

чтобы немного подстраховаться от потенциальных проблем.

Rating is hiddenLook
Как сократить время сборки с помощью кеширования контекста от Spring Test

Я тоже периодически так делаю, но мне постоянно высказывают, что это неправильно и что на самом деле надо мокать сетевые вызовы с помощью Wiremock.

Предлагаю компромисс.

Если по ресту ходит готовый клиент -- например, предоставленный сторонним сервисом или feign-клиент, сгенерированный по спеке -- то считаю вполне допустимым его мокать с помощью @MockBean (один раз в базовом тестовом классе, вестимо, чтобы не плодить контексты).

Если же мы используем что-то низкоуровненное -- всякие restTemplate, webClient и прочее, в общем пишем queryParams и pathVariables "руками", то лучше Wiremock. Хотя бы из-за того, что "given" будет написано в другом формате и более наглядно. Иначе получается масло масляное -- вызываем restTemplate с аргументами... и проверяем, что вызываем с правильными аргументами? Нехорошо.

Ещё лучше, конечно, если сторонний эндпоинт выдаст stub-ы в рамках Contract Testing-а (Spring Cloud Contract), но на практике я такого счастья пока не встречал.

Rating is hiddenLook
Jakarta Data и Persistence: Инструменты, которые меняют подход к работе с данными

А вообще, давайте без язвы, вроде повода не давал?

Мы оба даём друг другу поводы, высказывая утверждения, кажущиеся полной глупостью собеседнику, на которые тот с удовольствием посылает в гугл. Так что без язвительности в нашем деле никак, увы.

посмел предположить, что вы знаете разницу между стандартным read committed и read committed со снепшотами

А я и не знал. Я вообще не понял, о каких снепшотах вы пишете, мне показалось, что вы read committed и repeatable read путаете, поэтому да, я действительно подразумевал, что read committed всегда идёт с ними. И, конечно, в Postgres это так. Что сказать -- спасибо, что просветили.

но ни в стандарте, ни в sql server, например, это не так

Да, вы правы, и для меня это натурально открытие после надцати лет разработки. В своё оправдание могу сказать, что, кажется, MSSQL не так популярен в Java мире, как остальные три БД, я с ним -- так получилось -- ни разу не сталкивался.

Read skew может проявляться и в рамках одного запроса тоже

Я, пожалуй, возьму вашу ссылку и проверю коллег спором на деньги), уверен, многие ошибутся, а что -- в формулировке не будет сказано, на какой БД проверяем.

Единственно, мне сходу сложно представить, как read committed без snapshots в MSSQL можно вообще использовать, если там даже самый обычный `select ... from table` может неконсистентые данные возвращать?

Ок, с транзакциями разобрались, спасибо ещё раз, возвращаемся к EBean.

Ну если вам по прежнему не так важно, что чтением одной сущности бизнес логика далеко не ограничивается

Нет, я пишу прямо противоположное, мне важно, чтобы даже одна сущность была прочитана в консистентном состоянии.

Поэтому меня и смутил подход EBean, возникло ощущение, что с транзакциями и множественными запросами обращаются достаточно свободно, дочерние энтити можно загрузить частично, где-то вообще может быть null... т.е. где целостность-то?

Т.е. с JPA я могу быть уверен, что

@Transactional // очень желательно REPEATABLE_READ, конечно
void someMethod() {
   var entity = ... // откуда-то загружена или взята из другой энтити
   entity.doSomething();
   // из-за Spring Data JPA многие, увы, привыкли добавлять repo.save(), но он не нужен
}

.. метод doSomething() произведёт перевод сущности из одного консистетного состояния в другое.

А вот с EBean это неочевидно, хотя бы из-за https://ebean.io/docs/query/filterMany и вообще

Partially populated beans always expected

... т.е., если я правильно понял, за целостностью сущности предлагается следить самостоятельно, зато без декартова произведения?

Как по мне -- сомнительное преимущество.

Rating is hiddenLook
Jakarta Data и Persistence: Инструменты, которые меняют подход к работе с данными

Вы похоже подразумеваете, что read committed всегда идёт со snapshots, но ни в стандарте, ни в sql server, например, это не так, я уже упоминал.

Приписывать собеседнику утверждение, а потом его опровергать -- это не очень честный приём.

Read skew может проявляться и в рамках одного запроса тоже

Это как?!

из-за частично видимого апдейта другой транзакции

Что такое "частично видимый апдейт другой транзакции"?! Это как?

Только не надо ссылок, пожалуйста, напишите своими словами, можно в той нотации, на которую ссылаетесь.

вышеописанный read skew возможен даже при чтении сущностного графа одним запросом

Это как?!

что некоторые бд, тот же postgresql, предоставляют read committed вместе со snapshots

Нет, postgres не предоставляет.

Ну а Ebean тут можно похвалить, он предоставляет хотя-бы какую-то гарантию (что cartesian product не случится)

Ок, ещё раз напишу. Раз cartesian product не случится, значит запросов больше одного.

А что тогда, например, с Oracle предлагается делать? Включать SERIALIZABLE? Смириться с Read Skew? Не использовать Ebean? Открывать тикет?

JPA не умеет фильтровать OneToMany коллекции в JPQL... Ebean же позволяет это легко сделать ;) https://ebean.io/docs/query/filterMany.

В общем, вкупе с рассуждениями про Read Skew я делаю предположение, что ни автор EBean, ни вы как его пользователь, не видите смысла упарываться в консистентное чтение. Ну, т.е. частичная загрузка дочерних сущностей -- вас абсолютно не смущает, поскольку энтити (в вашем мире) -- это не объект с бизнес-инвариантами, а так... какая-то структура для чтения данных из базы. Точка зрения понятна, переубеждать смысла не вижу, спасибо за дискуссию.

Rating is hiddenLook
Jakarta Data и Persistence: Инструменты, которые меняют подход к работе с данными

Давайте разберёмся с определениями.

Entity может быть размазана по нескольким таблицам.

Если её читать несколькими запросами (и в это время другой процесс конкурентно её обновляет), получается Read Skew -- Entity может быть неконсистентна, бизнес-инварианты могут быть нарушены.

Чтобы избежать этого есть два подхода (и у каждого, конечно, своя "цена")

  • устанавливать уровень изоляции транзакции в REPEATABLE_READ или выше

  • на уровне READ_COMMITTED читать одним запросом -- `select ... from ... join ... join` -- это cartesian product

Если в Ebean заявляется, что

Ebean will never generate a SQL cartesian product

... то, если я верно понимаю, второй опции у разработчика вообще нет?

Что тогда, например, с Oracle предлагается делать? Включать SERIALIZABLE? Смириться с Read Skew? Не использовать Ebean?

Есть вообще в его документации какие-то рассуждения на эту тему?

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

Несколько запросов для разных сущностей -- это нормально, это не Read Skew. Read Skew -- это именно о неконсистентной одной сущности.

Теперь о LazyInitializationException (LIE).

OSIV и hibernate.enable_lazy_load_no_trans=true -- это грязные хаки, давайте их не разбирать. Правильно -- в рамках repeatable_read транзакции entity консистентна, можно обращаться к любому lazy-полю, за пределами транзакции к энтити обращаться не желательно, о чём, в том числе, сигнализирует LIE.

Я не совсем понял, что предлагает Ebean. По ссылке https://ebean.io/architecture/compare-jpa написано

Partially populated beans always expected

Это что вообще имеется в виду?

И вы пишете

вместо него Ebean возвращает null для незагруженных полей

Можете какой-то практический пример привести, пожалуйста, для чего это и почему это хорошо?

И, главное, как в таком случае отличить реальный null, т.е у поля нет значения, и когда оно не загружено?

Rating is hiddenLook
Jakarta Data и Persistence: Инструменты, которые меняют подход к работе с данными

Немного странно начинать обсуждение EBean VS JPA в статье про Jakarta Data, ну да ладно.

Сначала хотел написать длинный комментарий по каждому пункту (может и напишу), а пока зайду сразу с козырей.

Глянул по диагонали документацию EBean, не увидел, подскажите, пожалуйста: его автор и пользователи в курсе про Read/Write Skew?

(я по фене ботать не умею, так, чисто для сохранения стилистики)

Ebean говорит, братан, загружай че хочешь, я справлюсь, если надо я несколько запросов сделаю, мне не в падлу:

Ebean will never generate a SQL cartesian product

Невер, говорит, не в падлу, говорит... А если потом пойдут предъявы за Read Skew, кто отвечать за базар неконсистентность данных будет?!

Это, естественно, не отменяет, такого же вопроса к абсолютно любому SQL-фреймворку, мой поинт в том, что невозможно с порога заявить, что такой проблемы больше нет.

И то же самое ещё раз

  1. Его величество LazyInitializationException... В Ebean такая проблема отсутствует.

Т.е. OSIV (Open Session In View) тоже, выходит, "поощеряется" как в Spring Data JPA? А с Read Skew-то что?! Судя по ролику, который я глянул, транзакции былы разные.

LazyInitializationException же явно говорит, что "Алё, гараж! Вы что-то не то делаете, транзакция закрыта ваще-то уже!"

Rating is hiddenLook
Jakarta Data и Persistence: Инструменты, которые меняют подход к работе с данными

Всё дальше мы от ООП.

Без бутылки не разобраться.

Сначала долго ведут в сторону stateless

Заметьте, что update — это отдельная операция, а репозитории Jakarta Data всегда stateless. В них нет persistence контекста.

Потом вспоминают про stateful

Jakarta Data должна сама по себе поддерживать stateful persistence контексты, а это по сути означает новый API.

По сути это означает ещё одну имплементацию JPA к уже имеющимся (Hibernate, EclipseLink -- с этимя двумя работал, OpenJPA -- c этим нет)

Это абсолютно разные, фундаментально разные модели программирования. Невозможно рационально и эффективно создать абстракцию поверх этих двух моделей, а если вы попытаетесь, вы только создадите все разновидности путаницы в голове пользователя. 

Святая правда.

---

Всякие улучшайзинги по чтению из БД уже есть. И с типобезопасностью. Да, CriteriaAPI действительно не очень, поэтому есть Spring Data JPA, в нём Query by Example, а ещё QueryDSL (мой фаворит для сложных запросов) и, наверняка, много ещё, чего я не знаю.

Подозреваю, успех derived методов Spring Data JPA связан с тем, что во большинстве случаев их и достаточно. А на многословное имя, которое не влазит в экран (реализацию, по сути) можно и нужно сделать default метод -- бизнес-алиас -- в репозитории.

А в что с отображением изменения состояния энтити в БД?

Если говорить об операциях обновления данных, они, как правило, тривиальны.

Это точно?

Вот и Entity выглядят как настоящие, и @ManyToMany вроде бы есть, а вот (специально напишу без инкапсуляции, чтобы было наглядно)

book.getAuthors().get(0).setFirstName("Misha");
book.getAuthors().add(new Author("John", "Doe"));
library.upsert(book)

... работает?

Rating is hiddenLook
Честный взгляд на Spring Data JPA

Ок, короткая шпаргалка, что такое JPA, зачем и как с ним работать.

JPA -- это Java Persistence API, фреймворк, который позволяет мапить Java объекты на реляционную базу данных.

Что это значит на практике? Допустим, у нас есть такой класс (и объекты -- экземпляры этого класса)

public class Order {
   private Map<Item, Integer> itemsAndTheirAmounts = new HashMap<>();
   private Set<PromoCode> promoCodes = new HashSet<>(); 
   private Instant createdAt = Instant.now();
   private Money totalPrice = Money.of(0, Monetary.getCurrency("RUB"));
}

... в Item и PromoCode, в свою очередь, наверчено ещё что-то и т.д.

Пока мы работаем с ними в оперативной памяти -- всё ок, у но как только начинаем работать с внешним миром, нужно их как-то различать, для этого добавляется ID.

Entity = доменный класс + ID

Поскольку оперативная память всё ещё ограничена и энергозависима, нужно сохранять (persist-ить) эти объекты где-то, например, в реляционной БД.

Далее, есть такой подход как ООП -- объектно-ориентированное программирование. Одной из его идей является инкапсуляция -- это когда поля закрыты для изменений напрямую, но есть методы, которые гарантируют бизнес-целостность объекта.

В нашем примере это могут быть addItem(...), applyPromoCode(...) и т.д., которые изменяют состояние объекта, в том числе и пересчитывая totalPrice, благодаря чему (и юнит-тестам на них, конечно) мы можем быть уверены, что объект всегда консистентен.

Ещё раз, если у нас есть addItem(...) и removeItem(...) с соответсвующими проверками, есть гарантия, что количество товаров положительное, а итоговая цена пересчитана правильно.

Далее, все изменения состояния объекта хорошо бы отобразить обратно в БД. Этим и занимается JPA, что-то вроде

class Service {
    @Transactional
    void someMethod(...) {
        var entity = repo.findById(id);
        entity.update(...);
        // нет, repo.save(entity) здесь не нужен
    }
}

Единственный ли это подход? Конечно же нет.

Ещё можно вызывать разные SQL команды, а можно вообще ничего не перегонять на бекэнд, а всё делать сразу в БД с помощью хранимых процедур. У каждого подхода есть свои преимущества и недостатки.

К преимуществам JPA можно отнести, что бизнес-логика пишется на высокоуровневом языке Java, проверяется unit-тестами, а DML операции будут произведены фреймворком.

Ну, а недостатком считается факт, что в частных случаях с помощью SQL можно добиться большей производительности.

Однако, тут есть диллема. Допустим, мы хотим увеличить зарплату (правильнее, конечно, говорить ставку) сотрудников некоторого отдела на 10%. Какой подход лучше

@Transactional
void increaseSalary(...) {
   List<Employee> employees = repo.findAllByDepartment(...);
   employees.forEach(
       e -> e.increaseSalaryByPercent(10);
   )
}

... т.е. "выгрузить данные из БД, изменить, записать обратно по одному" или bulk update

update emloyees set salary = salary * 1.1 where department_id = :department_id;

...?

Очевидно, что вторая команда быстрее.

Но кто сказал, что метод increaseSalaryByPercent(...) настолько прост? Там могут быть (сейчас или добавятся потом) проверки на граничные значения, правила округления и т.д.

Кроме того, написав sql update мы создали вторую точку изменения salary, теперь придётся всегда об этом помнить и держать их в согласованном состоянии.

Всё рассуждения выше были про изменение состояния объектов, JPA в первую очередь об этом.

Кроме этого обычное занятие приложения это отображать их состояние AKA "читать данные из базы".

С объектной точки зрения корректный путь здесь -- это загружать объекты из базы и преобразовывать их в DTO.

Однако, очевидно, реляционные отношения и SQL предоставляют больше возможности и производительности. Если необходимо этим можно и нужно пользоваться, плата за это -- как в примере выше с bulk update -- поддержание ДВУХ подходов в синхронизированном состоянии.

P.S. Spring PetClinic -- довольно плохой пример использования JPA. Так делать не надо.

Rating is hiddenLook
Не используйте Lombok с JPA, пока не прочтете эту статью

Почитайте, плиз, про ООП и инкапсуляцию, подумайте, как сочетаются с ней билдер и сеттеры. К сожалению, это непопулярный взгляд, многие коллеги не видят никаких проблем в её нарушении, чай не проблема потом баги поправить, ещё и ещё.

Rating is hiddenLook
Не используйте Lombok с JPA, пока не прочтете эту статью

Чуток "причесал" вашу реализацию.

Но вообще лично я придерживаюсь подхода, который мне кажется более строгим:

  • entities не должны покидать границы транзакций

  • тогда и equals()/hashCode() переопредлять не нужно

Ну и посколько статья про Lombok:

  • как вы указываете, toString() можно только с явно указанными полями

  • @Builder считаю непременимым для Entity вообще, нужен явный конструктор без id, чтобы гарантировать бизнес-целостность

  • к @NoArgsConstructor лучше добавить access=AccessLevel.PROTECTED, JPA достаточно, а разработчикам он не нужен по причине выше

  • @AllArgsConstructor скорее не нужен, потому как он включает id, а он обычно генерируется sequence

  • @Setter тоже не нужен всё по той же причине необходимости бизнес-целостности

  • @Data отпадает, уже объяснено выше

Итого от Lombok-a остаются только `@ToString(onlyExplicitlyIncluded = true)` c явно указанными полями.

И @Getter. Геттеры нужны для а) конвертации entity в DTO, б) для тестов. В бизнес коде их быть не должно.

Rating is hiddenLook
JPA Entity. Загрузи меня не полностью

Vlad Mihalchea предлагает способ, как писать select new PostWithAuthorFlatDto без указания полного имени класса.

Rating is hiddenLook
Устойчивость микросервисных Spring приложений: роль аннотации @Transactional в предотвращении утечки соединений

Крайне интересно. Поделитесь техническими подробностями, пожалуйста.

Можете показать код, воспроизводящий баг? Который в баг-репорт прикладывали?

И вот эти комментарии

Если вы сюда попали, то делаете что-то уникальное

и

Если это вам нужно, то сделайте, пожалуйста, сами

... они в каких конкретно проектах/файлах/строчках?

Предполагаю, что вы ещё в контексте проблемы, раз

Недавно посмотрел код - ничего не поменялось :(

Rating is hiddenLook
Устойчивость микросервисных Spring приложений: роль аннотации @Transactional в предотвращении утечки соединений

Вы можете подтвердить баг тестовым проектом, демонстрирующем проблему? Отправили баг-репорт в Spring?

Атрибут transactionManager в `@Transactional` конечно же использовали?

Rating is hiddenLook
Устойчивость микросервисных Spring приложений: роль аннотации @Transactional в предотвращении утечки соединений

А, кстати, я правильно предполагаю, что entityManager.createStoredProcedureQuery вне транзакции не работает? Т.е. границы транзакции всё таки были где-то "выше"?

Но транзакция не закрывалась, потому что наружу выходило checked exception EDeliveryException?

И проблема решилась не столько добавлением @Transactional к createInboxMessage методу — это какбэ принципиально не верно — задавать границы транзакции в слое репозитория, а потому что перестали checked exception бросать

} catch (PersistenceException ex) {
    logger.error("DbRepository::createInboxMessage - Error creating notification", ex);
}

...?

Глушить эксепшены тоже, кстати, нехорошая практика.

В общем, вопросы есть к изложенному в статье.

Rating is hiddenLook
Hibernate — проблема декартова произведения при запросах с пагинацией

Вопрос не по теме (по теме напишу отдельный комментарий) -- вы как новый счёт клиенту добавляете?

clientEntity.addAccount(
    new AccountEntity(...)
);

или

accountRepository.save(
    new AccountEntity(
        clientEntity, 
        ...
    )
);

Rating is hiddenLook
Рецепты «приготовления» Hibernate, или решаем 5 проблем работы с фреймворком

Если это поле таки прочиталось, то получите бесполезное обновление

Это не так в случае lazy-скаляров. Когда они у вас заработают, посмотрите, как ведёт себя обновление.

Rating is hiddenLook
Рецепты «приготовления» Hibernate, или решаем 5 проблем работы с фреймворком

Опять же, с Lazy имеем кучу проблем, таких как n+1

Любая Lazy-загрузка -- это потенциальная N+1 проблема. Но одновременно и очевидный прирост производительности. `fetch = FetchType.EAGER` вы же над коллекциями не ставите, верно?

и работа за пределами транзакций

Я не вполне понимаю, что вы имеете в виду, хотя и догадываюсь. Как вы работаете с lazy-коллекциями "за пределами транзакций"? C lazy-скалярами всё то же самое.

пример для h2

БД значения не имеет, lazy-loading делает хибернейт.

без танцев с бубнами

Byte enhancement -- это валидный инструмент, а не танцы с бубном. Поскольку String -- final class, а не интерфейс, по-другому, увы, никак, хотя ещё ленивую загрузку LOB-a можно сымитировать с наследуемым классом (но там свои компромиссы), если byte enhancement почему-то смущает.

Видно, что никакой ленивой загрузки нет

Это пока нет) А внимательно перечитаете мой самый первый комментарий, погуглите -- уверен, заработает. Хинт: IDEA компилирует сама, byte enhancement не делает, поэтому запускайте тест напрямую с maven/gradle, вот "баг" на эту тему https://youtrack.jetbrains.com/issue/IDEA-159903/Hibernate-bytecode-instrumentation-code-is-being-overridden-by-IDEA

Rating is hiddenLook
Рецепты «приготовления» Hibernate, или решаем 5 проблем работы с фреймворком

Гм, раз вы меня дважды упрекаете, что я невнимательно читаю статью, придётся нарушить правило "overquoting -- зло".

Все примеры проверялись на Oracle и Postgres. Писались только изменённый поля.

Конечно, в любом случае пишутся только изменённые поля. Вопрос в том, что происходит под капотом БД. В случае Postgres мы имеем Vacuum, подробнее https://rbranson.medium.com/10-things-i-hate-about-postgresql-20dbab8c2791 раздел "#4: MVCC Garbage Frequently Painful". Для Oracle это не так, поэтому я и вставил оговорку "скорее всего".

>Во-вторых, "дефолтный" update-запрос по всем полям кешируется, а динамические будут каждый раз парсится

Современные СУБД решают эту проблему

Это очень смелое утверждение. Можете, пожалуйста, привести аргументы/доказательства?

Вы же сами начинаете с

Hibernate генерирует операторы SQL для операций CRUD всех объектов. Эти инструкции SQL генерируются один раз и кэшируются в памяти для повышения производительности.

Мой поинт в том, что "дефолтный" update по всем полям был сделан так именно из кеширования. Более того, даже in-clause (если уж приходится им пользоваться) на разном количество параметров оптимизуют с помощью hibernate.query.in_clause_parameter_padding, подробнее https://vladmihalcea.com/improve-statement-caching-efficiency-in-clause-parameter-padding/

Разница в поведении будет заметна, конечно, только под нагрузкой.

>Если не записывать обновленный LOB -- тогда и читать его не надо

Странное утверждение. 

Вы пишете

...операция обновления может стоить очень дорого... размер полей большой (например, LOB). Решить эту проблему поможет аннотация для сущности @DynamicUpdate.

Действительно, если в сущности есть LOB, он будет а) вычитываться из БД всегда, б) попадать в дефолтный update, даже если не изменился. Это не оптимально. Вы предлагаете @DynamicUpdate , а я предлагаю сделать его LAZY . Для этого не обязательно выносить его в отдельную таблицу.

>Отслеживание изменений полей -- dirty checking -- происходит всегда

Я обратного и не утверждал. 

Тем не менее, в статье есть

Или накладные расходы на отслеживание, или на запрос, содержащий все столбцы. 

Накладные расходы на отслеживание -- dirty checking -- происходит всегда*, @DynamicUpdate на них не влияет.

*всегда -- имеется в виду а) транзакция не read-only, б) сессия не stateless

Я описал ситуации, когда данная технология будет уместна, равно как и проблемы. 

А я пишу возражения к этими ситуациям, что, прежде чем браться за @DynamicUpdate:

  • если поле не обновляется вообще никогда, лучше его аннотировать @Column(updateable = false)

  • если в сущности LOB, есть смысл задуматься, не загружать ли его лениво

  • если в сущности много полей, а в разных бизнес-кейсах обновляются только некоторые из них, возможно, @DynamicUpdate будет оправдан. Осталось разобраться и померять, что такое "много" и "некоторые", и какой такой дизайн и кейсы получились.

я лично встречался с ситуациями, когда @DynamicUpdate резко повышал производительность

При всём уважении к вашему авторитету, ссылка на маленький тест демонстрирующий разницу между обычным обновлением и динамическим, была бы куда более весома. Пока я предполагаю, что таким образом (вместо lazy) боролись с LOB-ами.

Повторюсь,

без измерений под нагрузкой от @DynamicUpdate скорее всего будет псевдо-радость от "оптимизированных" SQL-запросов в логах и незначительная деградация производительности.

Rating is hiddenLook
Катастрофа с Hibernate 6.5 при обновлении на Spring Boot 3.3.0

С in-clause вообще лучше быть осторожным. В постгресе вроде бы ограничений нет, а в оракле, например, по дефолту не более 1000 аргументов -- соответственно, надо разбивать на чанки и конкатенировать результат.

Если бизнес-логика позволяет (как в данном конкретном случае), имеет смысл предварить в репозитории

interface ArticleRepository extends CrudRepository<Article, UUID> {
  default List<Article> findByPublisherId(List<UUID> ids) {
    if (ids.isEmpty()) {
     return Collections.emtpyList();
    }
    return _findByPublisherId(ids);
  }
  
  @Query("from Article where publisherId in :ids")
  List<Article> _findByPublisherId(List<UUID> ids);
}

Если метод совсем безобразно могут вызывать, ещё и проверку на null добавить.

Rating is hiddenLook
Рецепты «приготовления» Hibernate, или решаем 5 проблем работы с фреймворком

По поводу @DynamicUpdate -- спорно.

  1. Во-первых, в MVCC базах скорее пишется новое состояние записи целиком, а не отдельные поля.

  2. Во-вторых, "дефолтный" update-запрос по всем полям кешируется, а динамические будут каждый раз парсится -- правда, не уверен, на какой нагрузке это будет актульно.

  3. Если не записывать обновленный LOB -- тогда и читать его не надо, либо вынести его в наследуемый класс, либо `@Basic(fetch = FetchType.LAZY)` c hibernate-enhance-maven-plugin.

  4. Отслеживание изменений полей -- dirty checking -- происходит всегда, если транзакция не read-only, @DynamicUpdate тут не влияет.

  5. @DynamicUpdate может быть актуален, если "дефолтный" update по всем полям зацепляет поле, которое а) не изменилось б) но в БД на него повешен триггер и происходит какой-то side effect.

В общем, без измерений под нагрузкой от @DynamicUpdate скорее всего будет псевдо-радость от "оптимизированных" SQL-запросов в логах и незначительная деградация производительности.

Rating is hiddenLook

Information

Rating
6,585-th
Location
Абу Даби, Абу Даби, О.А.Э.
Registered
Activity

Your account

Sections

Information

Services

Support
© 2006–2025, Habr