metaclass: (Default)
metaclass ([personal profile] metaclass) wrote2010-03-17 08:02 pm

Автоматический вывод типов запросов и bind-параметров в СУБД

Я знаю, что меня читают люди, использующие всякие разнообразные СУБД.
В связи с этим у меня есть такой хитрый вопрос, связанный с использованием bind-параметров в запросах: насколько распространена среди разных серверов (а так же клиентских либ и компонентов доступа) такая фича, что при парсинге запроса он возвращает список параметров и их типы?

Дело в том, что более-менее напрямую я использую только Firebird и он после prepare возвращает информацию о используемых параметрах и их типах (когда-то в версии 1.5.х, что ли, его плющило на тему вывода типов, но давно было, вроде исправили и вообще я уже забыл что там было).

Т.е. если мы представим селект как функцию вроде select :: p0 -> p1 -> p2 -> ... -> [(f0,f1,...)] то Firebird выводит тип этой функции из текста запроса и информации о таблицах. Это невероятно удобно, т.к. позволяет использовать SQL запрос+пару таблиц с дополнительными метаданными в качестве DSL для описания достаточно большого класса отчетов, покрывающего 90% всех потребностей в опердени. Т.е я из списка параметров и таблицы типа (параметр, юзеровское имя, справочник, формат) генерю UI для ввода этих самых параметров, а из типа результата запроса дельфи автоматом заполняет всю метаинформацию для DBGrid.

Из других СУБД я использую MSSQL и Sqlite, но через ADO.NET, в котором параметры, судя по всему, принципиально не заполняются автоматически и их нужно вносить в DbCommand или SqlCommand вручную. Т.е. я не знаю, умеет ли сервер это делать вообще. Это выбешивает просто невероятно, т.к. работы становится в несколько раз больше. Я уже подумываю написать собственный парсер запросов или вообще DSL с выводом типов и генерацией SQL запросов для описания запросов/датасетов, чтобы не заниматься этой многословной хренью.

PostgreSQL заполняет bind-параметры после prepare, но непонятно кто это делает - сервер, клиентская либа или компоненты доступа. И на сервер он гонит запросы плейн-текстом, т.е. запросто может оказаться что подстановка вообще делается клиентской либой в лоб, без всякого вывода типов.

А как вообще принято эти параметры заполнять и кто это делает - сервер, клиентская либа, компоненты доступа или вообще вручную по жизни?

[identity profile] rssh.livejournal.com 2010-03-17 08:44 pm (UTC)(link)
1. Так как в Jdbc есть функция getResultSetMetainfo(), то все БД, поддерживающие jdbc это так или иначе умеют типизировать результаты запросов

2. С параметрами сложнее. В общем случае - не знаю; в postgresql есть pQdescribePrepared http://www.postgresql.org/docs/8.4/interactive/libpq-exec.html#LIBPQ-EXEC-MAIN (И кстати запросы он на чсервер отадет по разному в зависимотси от вресии протокола)

// кстати - а когда надо знать именно выведенный тип параметров ?
Кажись наоборот - ты же их (параметры) даешь всегда.

[identity profile] metaclass.livejournal.com 2010-03-17 08:50 pm (UTC)(link)
Ну вот я описал параметр с именем в запросе, например в качестве фильтра для поля типа integer, типа select ... from operations where oper_dept_id=:dept_id
Я получаю в объекте, описывающем запрос, список из одного параметра с именем dept_id и типом integer. Мне этой информации уже достаточно, чтобы знать, какой гуй-элемент сгенерировать для ввода и валидации этого параметра (т.е. для себя я уже имею пригодный гуй), а если еще добавить таблицу с метаданными, где по имени параметра я найду юзер-френдли подпись к параметру, формат ввода, справочник и прочее - то оно уже и в продакшен готово.

[identity profile] rssh.livejournal.com 2010-03-17 09:50 pm (UTC)(link)
а, понятно немного
(но если у тебя есть таблицв метаданных -- логично бы туда и тип вписать а не спрашиваьть у БД)

[identity profile] metaclass.livejournal.com 2010-03-17 10:26 pm (UTC)(link)
Тут аспект в том, что таблица эта и записи в ней опциональные - они нужны для красивостей. А для работы достаточно одного запроса:)