parser

Написать ответ на текущее сообщение

 

 
   команды управления поиском

Ответ

Олег 18.04.2003 12:06

"приводите пример кода полностью совпадающий с предлагаемым мной :)"
Полностью, да не полностью. Сравните:

$name[^string:sql{select name where id=@id}[
$.prepared(1)
$.id[...]
]]

$id[123]
$name[^string:sql{
select NAME from TABLE where ID=:id;
id=$id
}]

В первом случае кэшированием запросов занимается парсер, для поддержки доп. возможностей изменяется формат вызова

query(services, connection, statement, offset, limit, handlers)

до

queryEx(services, connection, statement, offset, limit, int params_count, void* params, bool prepare, handlers)

затем до

query2(services, connection, transaction, readTransaction, statement, offset, limit, int params_count, void* params, bool prepare, handlers)

это сложно и не нужно, не спорю.

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

Что касается CGI-версии: здесь разговор идет только о архитектуре isapi и только о использованиии парсера в качестве front-end интерфейса для сложных информационных систем (каковых на том же interbase существует великое множество: складских, бухгалтерских, телекоммуникационных, архивных…) Парсер вполне способен заменить собой родные интерфейсы разных производителей (например, UserPortal от Navision или связку ASP -> ADO -> MS SQL), поскольку проще написать специфичный драйвер для парсера, чем изучать конкретный интерфейс или искать специалиста по нему. Короче, займусь написанием патча.