Управление @NamedNativeQuery и схемой

У меня есть много EntityManager, по одному на схему, которая у меня есть (я использую файл entity-mappings для сопоставления EM со схемами). Оно работает.

Когда я использую @NamedQuery, он работает как шарм, но когда я использую схему @NamedNativeQuery, она не используется. Я должен квалифицироваться с этим SELECT foo FROM schema.table.

Это правильное поведение?

Я думаю, что невозможно параметр @NamedNativeQuery для динамической передачи схемы (я считаю, что только столбцы могут быть динамикой, а не таблицами, схемами или чем-то еще), так как я могу использовать @NamedNativeQuery с динамической схемой, пожалуйста?


person Olivier J.    schedule 19.12.2012    source источник


Ответы (2)


Выдержки из документации:

  • NamedNativeQuery: указывает именованный собственный SQL-запрос. Имена запросов привязаны к единице сохраняемости.
  • NamedQuery: задает статический именованный запрос на языке запросов Java Persistence. Имена запросов привязаны к единице сохраняемости.

Прямо не указано, что NamedNativeQuery является статическим, но оба имеют одинаковую область действия и не могут быть изменены впоследствии, и это желаемое поведение.

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

person Nayan Wadekar    schedule 20.12.2012
comment
Я знаю, что могу это сделать. Итак, для вас невозможно использовать именованный собственный запрос с динамической схемой? Тай - person Olivier J.; 20.12.2012
comment
@ОливьеДж. Да, нельзя передать таблицу/схему и т. д. в качестве параметра именованному запросу - person Nayan Wadekar; 20.12.2012
comment
хорошо, я сгенерирую свой запрос со строкой динамически. Спасибо - person Olivier J.; 20.12.2012
comment
Динамическое создание любых строк запроса может представлять угрозу безопасности, если значения берутся из неуправляемых источников, таких как пользовательский ввод, поэтому это следует делать с осторожностью. Кроме того, динамические запросы не могут использовать функции управления производительностью пула соединений для повторного использования запросов и планов выполнения в базе данных. Вместо этого будет использовать логику для поиска namedQueryX по сравнению с namedQueryY на основе любых условий, при этом каждый NamedQuery привязан к своим соответствующим единицам сохранения. - person Darrell Teague; 13.03.2013
comment
@DarrellTeague Да, существует риск для безопасности, если вводить данные непосредственно в запрос вместо установки параметров/использования именованных запросов. Желательно иметь отдельный блок сохраняемости. - person Nayan Wadekar; 14.03.2013