Querydsl JPQLQuery fetchВсе цели - PullRequest
Новая
       17

Querydsl JPQLQuery fetchВсе цели

0 голосов
/ 21 октября 2019

Мы обновляем проект с Querydsl версии 3 до версии 4. Изменился способ работы подзапросов. В версии 3 вы могли бы написать подзапрос, подобный следующему: 

ListSubQuery<Long> subQueryResult = new JPASubQuery()
    .from(domain)
    .where(domain.prefix.eq(prefix))
    .list(domain.id);

Я обновил код до: 

JPQLQuery<Long> subQueryResult = from(domain)
    .select(domain.id)
    .where(domain.prefix.eq(prefix))
    .fetchAll();

Мой вопрос о методе fetchAll Я добавил в конце запроса. Я не уверен, если это необходимо. Я предполагал, что это замена для списка , но мой коллега указал, что тип возвращаемого значения - просто JPQLQuery, который уже возвращается , где .

JavaDoc для fetchAll заявляет:

Добавить флаг "fetchJoin all properties" к последнему определенному соединению.

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

1 Ответ

1 голос
/ 21 октября 2019

Вам нужно fetchJoin(), чтобы действительно загрузить свойства, помеченные как «ленивые». Это мало что значит для вашего примера (только загрузка значения domain.id), но если вы начнете загружать сложные типы данных в подзапросе, вы, возможно, захотите, чтобы ваши данные присутствовали для корневого запроса.

При этом, имея сложный тип данных с "большим количеством" ленивых атрибутов, вы можете не захотеть / не нужно добавлять флаг выборки для всех них, а только для тех, которые вам действительно нужны для запроса. Так что просто вызов fetchAll может быть не то, что вам нужно все время. В случае сомнений я бы предложил включить ведение журнала sql и проанализировать сгенерированный sql, каждый из которых JOIN FETCH представляет собой загруженную нагрузку.

И могу ли я безопасно удалить его из своего подзапроса

Итак, TL; DR: если вам никогда не приходилось думать о JOIN FETCH в прошлом, то на самом деле: да, вы должны быть в состоянии безопасно игнорировать fetchAll, так как это не добавит ничего нового кваши запросы. Это должен быть просто удобный способ избавить вас от некоторого стандартного кода на тот случай, если вы действительно захотите загрузить свои данные в полном объеме.

...