Я работаю над приложением сервлета Java, которое должно создавать очень динамичные операторы SQL для специальных целей отчетности. Основная функция приложения — передать набор именованных параметров HTTP-запроса в предварительно закодированный запрос и создать хорошо отформатированную таблицу вывода. Я использовал Spring MVC и инфраструктуру внедрения зависимостей, чтобы хранить все свои SQL-запросы в XML-файлах и загружать их в приложение для создания отчетов вместе с информацией о форматировании таблицы. Со временем требования к отчетности стали более сложными, чем возможности существующих фреймворков сопоставления параметров, и мне пришлось писать свои собственные. Это было интересное упражнение в разработке, и оно создало основу для сопоставления параметров, намного более надежную, чем что-либо еще, что я мог найти.
Новые сопоставления параметров выглядели так:
select app.name as "App",
${optional(" app.owner as "Owner", "):showOwner}
sv.name as "Server", sum(act.trans_ct) as "Trans"
from activity_records act, servers sv, applications app
where act.server_id = sv.id
and act.app_id = app.id
and sv.id = ${integer(0,50):serverId}
and app.id in ${integerList(50):appId}
group by app.name, ${optional(" app.owner, "):showOwner} sv.name
order by app.name, sv.name
Прелесть получившейся инфраструктуры заключалась в том, что она могла обрабатывать параметры HTTP-запроса непосредственно в запросе с надлежащей проверкой типов и проверкой ограничений. Никаких дополнительных сопоставлений для проверки ввода не требуется. В приведенном выше примере запроса параметр с именем serverId будет проверен, чтобы убедиться, что он может быть приведен к целому числу и находится в диапазоне 0–50. Параметр appId будет обрабатываться как массив целых чисел с ограничением длины 50. Если поле showOwner присутствует и имеет значение "true", биты SQL в кавычках будут добавлены к сгенерированному запросу для дополнительных сопоставлений полей. field Доступны еще несколько сопоставлений типов параметров, включая необязательные сегменты SQL с дополнительными сопоставлениями параметров. Он допускает такое сложное сопоставление запросов, какое только может придумать разработчик. Он даже имеет элементы управления в конфигурации отчета, чтобы определить, будет ли заданный запрос иметь окончательные сопоставления с помощью PreparedStatement или просто будет выполняться как предварительно созданный запрос.
Для примера значений запроса Http:
showOwner: true
serverId: 20
appId: 1,2,3,5,7,11,13
Это выдаст следующий SQL:
select app.name as "App",
app.owner as "Owner",
sv.name as "Server", sum(act.trans_ct) as "Trans"
from activity_records act, servers sv, applications app
where act.server_id = sv.id
and act.app_id = app.id
and sv.id = 20
and app.id in (1,2,3,5,7,11,13)
group by app.name, app.owner, sv.name
order by app.name, sv.name
Я действительно думаю, что Spring или Hibernate или одна из этих платформ должны предлагать более надежный механизм сопоставления, который проверяет типы, допускает сложные типы данных, такие как массивы и другие подобные функции. Я написал свой движок только для своих целей, он не совсем подходит для общего выпуска. На данный момент он работает только с запросами Oracle, и весь код принадлежит крупной корпорации. Когда-нибудь я возьму свои идеи и создам новую среду с открытым исходным кодом, но я надеюсь, что один из существующих крупных игроков примет вызов.
person
Natalia
schedule
02.02.2009
