Как сделать двунаправленный запрос

ID=2, Name=Quine,Keith G.

4 steps forward

ID=3, Name=Jones,Elvira A.

ID=4, Name=Townsend,Howard D.

ID=5, Name=Uberoth,Juanita D.

ID=6, Name=Van De Griek,Michael K.

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

Таким образом, составить новый класс или набор классов, аналогичные по интерфейсу штатным, не составляет особых проблем. За исключением того, что имея один запрос мы должны будем сделать из него два. Для этого введем некоторую некрасивость - в теле запроса потребуем указания обеих сортировок и разделителей, ограничивающих собственно запрос и сортировки. Выберем в качестве разделителя символы $$$ и будем полагать, что запрос строится по схеме:

select ...

from ...

where ...

$$$ order by ... asc

$$$ order by ... desc

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

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

Внимание привлекает поведение функций доступа, например, класс %DynamicSQLQuery, функция Fetch:

n %qref,rtn Set %qref=$lg(qHandle,1),rtn=$lg(qHandle,2)

Quit:%qref=""!(rtn="") $$$ERROR($$$GeneralError,"Query not Prepared")

QUIT $$Fetch^@rtn

Как видно по тексту, сама функция принимает и передает qHandle по ссылке, но к сгенерированной рутине обращается, передавая значения через локальные переменные. Код сгенерированной рутины закрыт, но судя по тому, что состояние qHandle должно быть передано наружу, ее модифицировать может только вызываемая рутина $$Fetch^@rtn. Других проблемных моментов я не нашел, поэтому к делу.

Экспортируем классы %DynamicQuery, %DynamicSQLQuery и $ResultSet в cdl. Дописываем к их именам символ 2 и правим коды так, чтобы у %DynamicSQLQuery2 была внутренняя поддержка обратной прокрутки, более развернутого хендла, чтобы у класса %DynamicQuery использовался запрос типа %DynamicSQLQuery2 и чтобы класс %ResultSet2 имел еще одну функцию, обращающуюся к FetchBack.

Получившиеся у меня для Cache' 4.1.9 классы можно загрузить по ссылке в конце страницы.

Проверочный код примерно следующего вида:

run()

n result,i

Set result=##class(%ResultSet2).%New("%DynamicQuery2:SQL")

Do result.Prepare("select ID, Name from NameList

$$$ order by ID ASC $$$ order by ID DESC")

Do result.Execute()

f i=1:1:4 d

. d result.Next()

. Write result.Get("ID"),result.Get("Name"),!

f i=1:1:2 d

. d result.Prior()

. Write result.Get("ID"),result.Get("Name"),!

f i=1:1:4 d

. d result.Next()

. Write result.Get("ID"),result.Get("Name"),!

Do result.%Close()

q

В результате его работы в терминале выдаются примерно следующие данные:

USER>d run^fetch()

1Presley,Samantha H.

2Quine,Keith G.

3Jones,Elvira A.

4Townsend,Howard D.

3Jones,Elvira A.

2Quine,Keith G.

3Jones,Elvira A.

4Townsend,Howard D.

5Uberoth,Juanita D.

6Van De Griek,Michael K.

Поскольку данные сгенерированы случайным образом, в Вашем случае они могут выглядеть иначе.

К неприятностям метода можно отнести следующие обстоятельства -

Использование нестандартного набора классов

Но что мешает изменить штатные классы, если это очень нужно?

Использование нештатной sql конструкции

Но штатной нет, а какая разница, какие символы будут там написаны? Все равно ведь что-то писать надо будет.

В версии Cache 5 появился дополнительный класс %ScrollableResultSet, который примерно то же самое и делает, и кроме того объект этого класса может быть сохранен в базе данных. Это позволяет просто организовать подкачку страниц например для веб интерфейса - выдачу строк порциями с сохранением контекста запроса между обращениями к базе например.