Нежелательное неявное внутреннее соединение в HQL-запросе

Question

Я пытаюсь написать выражение QueryDSL для выбора значения столбца.Это несколько соединений от таблицы «from»:

a.b.c.get(0).field

, где b может быть нулевым объектом, но если нет, то в коллекции c будет не более 1 записи.я хочу что-то вроде

new CaseBuilder()
 .when(a.b.isNotNull().and(a.b.c.isNotEmpty()))
 .then(a.b.c.get(0).field.stringValue())
 .otherwise(Expressions.stringTemplate("''"))

Это неявно создает внутренние объединения с таблицами b и c в SQL, а это не то, что я хочу, потому что это не возвращает результатов, когда b на самом делеnull.Добавление явных левых внешних объединений в любом случае не останавливает неявные объединения.Я уверен, что не думаю, что это правильно, пожалуйста, помогите мне разобраться: -)

Answer 1

Когда я добавил поддержку неявных объединений в jOOQ , я исследовал эту тему и наткнулся на это "ограничение" / дизайн в Hibernate. Недавно я сообщил об этой проблеме в список рассылки Hibernate-dev, поскольку я ясно считаю, что это ошибка: http://lists.jboss.org/pipermail/hibernate-dev/2018-February/017299.html

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

Вы можете прочитать ответы на это письмо, особенно это обоснование Стива Эберсола:

Я говорил, что больше не могу смотреть на HQL / JPQL и скажите, какие соединения SQL будут использоваться для этого, если зависит от сопоставленной ассоциации. Этот подход был упомянут ранее в теме. Но вы пояснили, что вы имеете в виду, что неявные объединения должны просто всегда интерпретировать как внешнее соединение.

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

Не думаю, что это будет исправлено в ближайшее время в Hibernate. Итак, обходной путь здесь заключается в том, чтобы явно создавать все ваши внешние объединения и не использовать какие-либо неявные объединения, когда вы ожидаете, что они произведут внешние объединения.