Я працював над додатком сервлетів Java, який потребує побудови дуже динамічних операторів SQL для цілей звітування adhoc. Основна функція програми - подавати купу іменованих параметрів запиту 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 в лапках будуть додані до згенерованого запиту для необов'язкових відображень полів. поле Доступно ще кілька відображень типу параметрів, включаючи необов'язкові сегменти 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, і весь код належить великій корпорації. Колись я можу взяти свої ідеї та створити нову рамку з відкритим кодом, але сподіваюся, що хтось із існуючих великих гравців вирішить цю проблему.