Запрос критериев JPA - как избежать дублирования соединений

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

Например, у меня есть следующая структура таблиц и сущностей JPA:

ACCOUNT
      ACCOUNT_ID
      ACCOUNT_TYPE


PERSON
      NAME
      AGE
      ACCOUNT_ID ( FK TO ACCOUNT ) 
      ADDRESS_ID ( FK TO ADDRESS ) 

ADDRESS
      ADDRESS_ID
      LOCATION
      COUNTRY

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

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

CriteriaBuilder cb = entityManager.getCriteriaBuilder();
    CriteriaQuery<Account> cq = cb.createQuery(Account.class);

    cq.select(accountRoot).where(
     cb.and(
      cb.equal(accountRoot.join(Account_.person).get(Person_.name),"Roger"),
      cb.greaterThan(accountRoot.join(Account_.person).get(Person_.age),18),
      cb.equal(accountRoot.join(Account_.person)                                   
              .join(Person_.address).get(Address_.country),"United States")
      )
     )

     TypedQuery<Account> query = entityManager.createQuery(cq);
     List<Account> result = query.getResultList();

Приведенный выше код сгенерирует SQL с несколькими соединениями одной и той же таблицы:

 Select
        account0_.account_id as account1_2_,
        account0_.account_type as account2_2_
    from
        account account0_
    inner join
        person person1_
            on account0_.account_id=person1_.account_id
    inner join
        address address2_
            on person1_.address_id=address2_.address_id
    inner join
        person person3_
            on account0_.account_id=person3_.account_id
    inner join
        person person4_
            on account0_.account_id=person4_.account_id
    inner join
        person person5_
            on account0_.account_id=person5_.account_id
    inner join
        address address6_
            on person5_.address_id=address6_.address_id
    where
        person3_.name=?
        and person4_.age>18
        and address6_.country=?

Простое решение - сохранить экземпляры объединений для повторного использования в нескольких таких предикатах:

   Root<Account> accountRoot = cq.from(Account.class);
   Join<Account,Person> personJoin= accountRoot.join(Account_.person);
   Join<Person,Address> personAddressJoin = accountRoot.join(Person_.address);

   cq.select(accountRoot).where(
     cb.and(
      cb.equal(personJoin.get(Person_.name),"Roger"),
      cb.greaterThan(personJoin.get(Person_.age),18),
      cb.equal(personAddressJoin.get(Address_.country),"United States")
      )
     )

Хорошо, это работает, но с настоящим сложным кодом с несколькими таблицами и условными объединениями для кодов имеет тенденцию превращаться в спагетти-код! Поверьте мне !

Как лучше этого избежать?


person Eduardo Fabricio    schedule 21.07.2015    source источник
comment
У вас есть несколько соединений в SQL, потому что ваш код имеет много избыточных вызовов join. Что вы ожидали, что произойдет? Вызовите join один раз для каждого действительно необходимого соединения и повторно используйте возвращенный экземпляр Join. Вы уже создали два Join экземпляра, которые вам нужны - просто используйте их!   -  person Rob    schedule 21.07.2015
comment
@Rob Извините, спасибо за ваш комментарий, вчера я отправил неполный вопрос, я его исправил. Я знаю, что это было неправильно. В моем первом опыте работы с запросом критериев и объединениями я допустил эту ошибку и должен был опубликовать два кода неправильно и исправлено. Вопрос исправлен! Однако я не думаю, что этот ответ неправильный, это просто предложение избежать его в сложном запросе критериев, у меня есть хороший опыт использования этой стратегии в моей работе, поэтому я хочу поделиться этим решением, но хорошо, если это ваш мнение.   -  person Eduardo Fabricio    schedule 22.07.2015


Ответы (2)


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

public class AccountCriteriaBuilder {

        CriteriaBuilder cb;
        CriteriaQuery<Account> cq;

        // JOINS INSTANCE
        Root<Account> accountRoot;
        Join<Account,Person> personJoin;
        Join<Person,Address> personAddressJoin;

        public AccountCriteriaBuilder(CriteriaBuilder criteriaBuilder) {
            this.cb =  criteriaBuilder;
            this.cq = cb.createQuery(Account.class);
            this.accountRoot = cq.from(Account.class);
        }

        public CriteriaQuery buildQuery() {
            Predicate[] predicates = getPredicates();
            cq.select(accountRoot).where(predicates);
            return cq;
        }

        public Predicate[] getPredicates() {

           List<Predicate> predicates = new ArrayList<Predicate>();

           predicates.add(cb.equal(getPersonJoin().get(Person_.name), "Roger"));
           predicates.add(cb.greaterThan(getPersonJoin().get(Person_.age), 18));
           predicates.add(cb.equal(getPersonAddressJoin().get(Address_.country),"United States"));

           return predicates.toArray(new Predicate[predicates.size()]);
        }

        public Root<Account> getAccountRoot() {
            return accountRoot;
        }

        public Join<Account, Person> getPersonJoin() {
            if(personJoin == null){
                personJoin = getAccountRoot().join(Account_.person);
            }
            return personJoin;
        }

        public Join<Person, Address> getPersonAddressJoin() {
            if(personAddressJoin == null){
                personAddressJoin = getPersonJoin().join(Person_.address);
            }
            return personAddressJoin;
        }


}

«Козырёк в дыре» - это ленивая загрузка для каждого необходимого экземпляра соединения, это позволит избежать дублирования соединений, а также упростить процесс навигации.

Наконец, просто вызовите конструктор, как показано ниже:

AccountCriteriaBuilder criteriaBuilder = new AccountCriteriaBuilder(em.getCriteriaBuilder());
TypedQuery<Account> query = em.createQuery(criteriaBuilder.buildQuery());
List<Account> result = query.getResultList();

Наслаждаться :)

person Eduardo Fabricio    schedule 21.07.2015
comment
Чтобы увидеть, как он работает, у меня есть полный образец его реализации с H2 в базе данных памяти и встроенным причалом .. Просто клонируйте и запускайте github.com/dufabricio/hibernate-sample - person Eduardo Fabricio; 21.07.2015
comment
Думаю, я этого не понимаю. Ваше простое решение - 8 строк кода. Ваше решение Builder - это что-то вроде 30 строк кода, делающего то же самое. Вы не можете оправдать это, если дополнительная сложность не может быть перенесена в базовый класс, который используется многими сущностями или амортизируется по множеству различных запросов. На мой взгляд, использование паттерна ради паттерна - это антипаттерн. - person Rob; 22.07.2015
comment
Хорошо я согласен ! этот пример кода не является настоящим кодом спагетти, я просто создаю образец для объяснения ... это не настоящий случай .. Но, хорошо указал @Rob, я постараюсь сделать образец более похожим на мой реальный код, чтобы лучше его оправдать .. это потрясающая часть Интернета .. Свобода слова! - person Eduardo Fabricio; 22.07.2015
comment
В моей жизни были моменты, когда я много думал об этих концепциях, паттернах, антишаблонах и т. Д. Сегодня для меня… приложения должны работать нормально. .Просто это ! ;) .. Опять же это только мое мнение ..! еще раз спасибо за свой вклад! Ваши комментарии показывают мне, что этот образец не так понятен. - person Eduardo Fabricio; 22.07.2015
comment
Есть ли способ заставить Fetch повторно использовать существующее соединение? - person Glapa; 09.03.2017

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

public class CriteriaApiUtils {
  public static <X, Y> ListJoin<X, Y> join(Root<X> criteriaRoot,
                                             ListAttribute<? super X, Y> attribute,
                                             JoinType joinType
  ) {
    return (ListJoin<X, Y>) criteriaRoot.getJoins().stream()
        .filter(j -> j.getAttribute().getName().equals(attribute.getName()) && j.getJoinType().equals(joinType))
        .findFirst()
        .orElseGet(() -> criteriaRoot.join(attribute, joinType));
  }
}
person user1096250    schedule 21.09.2020
comment
Я использовал нечто подобное - это гораздо менее инвазивно, чем создание конструктора, и его можно повторно использовать для любого типа запроса критериев. - person matt forsythe; 19.11.2020