Обходной путь не требуется, поскольку это не является недостатком технологии. Нужно менять не JPQL, а ваш выбор технологии. В JPQL вы не можете даже выбрать данные из таблицы. Вы выбираете из классов, и они могут быть сопоставлены с несколькими таблицами одновременно, что приводит к объединению SQL для самых простых запросов. Описывать такое соединение было бы бессмысленно. И даже если бы вы могли описать таблицу, вы используете не имена столбцов в JPQL, а свойства объектов. Описывать таблицы в JPQL нет смысла.
JPQL предназначен для запросов объектов, а не таблиц. Кроме того, он предназначен для статической работы (где классы отображаются раз и навсегда), а не для динамических вещей, таких как отображение таблиц на объекты на лету или проверка базы данных в реальном времени (для этого предназначен AR ror). Динамическое обнаружение свойств не является частью этого.
В зависимости от того, чего вы действительно хотите достичь (мы знаем только то, что вы пытаетесь сделать, это отличается), у вас есть два основных варианта:
, если вы пытаетесь написать часть программного обеспечения динамическим способом, чтобы он приспосабливался к изменениям в схеме - отбрасывайте JPQL (или любой другой ORM). Java-классы должны быть статичными, вы не можете отобразить их в динамические таблицы (или вырастить новые атрибуты). Используйте наборы строк, они отлично работают, и они позволят вам использовать SQL;
если вы создаете умную библиотеку, которая может совместно использоваться многими проектами и поэтому должны работать со многими различными статическими сопоставлениями, используйте API отражения, чтобы найти свойства объектов, для которых вы запрашиваете. Имена столбцов в таблице вам все равно не помогут, поскольку в запросах JPQL вы должны использовать имена, определенные в отображениях.