Spring / Hibernate: двунаправленное сопоставление без синхронизации только для запросов JPQL

При двунаправленном отображении между объектами (например, @ManyToOne@OneToMany) аналог должен быть синхронизируется при каждом изменении, особенно при использовании кэша уровня 2nd. Обычно это делается с помощью вспомогательных методов. Эти вспомогательные методы не работают хорошо, если часть Many содержит много записей, потому что каждый раз выбирается весь набор. Простым примером может быть объект Store, у которого есть nProducts, тогда как n очень большой. Добавление нового Product к Store потребовало бы, чтобы Store получил весь список Products, чтобы наконец добавить его в набор (см. Пример кода ниже).

Можно утверждать, что при моделировании такой связи лучше было бы представить однонаправленную ассоциацию от Product к Store. Однако в нашем приложении мы используем много запросов JPQL. В JPQL очень удобно объединять объекты с обеих сторон.

Видите ли вы какие-либо проблемы при отображении отношения @OneToMany в сущности Store, когда Many на самом деле означает много, а не только несколько, и просто делает поле закрытым, без геттеров и сеттеров, при условии, что все отношение лениво выбирается? Насколько я понимаю, Hibernate просто нужно поле для отображения отношения. А если набор частный, проблем с производительностью возникнуть не должно?


Сущность Product:

@Entity
@Table(name = "product")
@Cache(usage = CacheConcurrencyStrategy.NONSTRICT_READ_WRITE)
public class Product {

  @ManyToOne(fetch = FetchType.LAZY)
  private Store store;

  // setter, getter, helper methods
}

Сущность Store:

@Entity
@Table(name = "store")
@Cache(usage = CacheConcurrencyStrategy.NONSTRICT_READ_WRITE)
public class Store {

  @OneToMany(mappedBy = "products", fetch = FetchType.LAZY)
  @Cache(usage = CacheConcurrencyStrategy.NONSTRICT_READ_WRITE)
  private Set<Product> products;

  // setter, getter, helper methods
}
Пользовательский скаляр GraphQL
Пользовательский скаляр GraphQL
Листовые узлы системы типов GraphQL называются скалярами. Достигнув скалярного типа, невозможно спуститься дальше по иерархии типов. Скалярный тип...
Как вычислять биты и понимать побитовые операторы в Java - объяснение с примерами
Как вычислять биты и понимать побитовые операторы в Java - объяснение с примерами
В компьютерном программировании биты играют важнейшую роль в представлении и манипулировании данными на двоичном уровне. Побитовые операции...
Поднятие тревоги для долго выполняющихся методов в Spring Boot
Поднятие тревоги для долго выполняющихся методов в Spring Boot
Приходилось ли вам сталкиваться с требованиями, в которых вас могли попросить поднять тревогу или выдать ошибку, когда метод Java занимает больше...
Полный курс Java для разработчиков веб-сайтов и приложений
Полный курс Java для разработчиков веб-сайтов и приложений
Получите сертификат Java Web и Application Developer, используя наш курс.
12
0
609
1
Перейти к ответу Данный вопрос помечен как решенный

Ответы 1

Ответ принят как подходящий

Нет, в этом нет ничего плохого, я тоже часто использовал эту технику. Конечно, просто убедитесь, что к полю не осуществляется доступ в каком-то контексте (например, автоматические компоновщики toString и подобные утилиты, которые вы можете использовать).

Кроме того, вам не нужна аннотация @Cache на нем, поскольку вы все равно никогда не получите доступ к коллекции, поэтому она никогда не будет кэширована.

Другие вопросы по теме