Pull to refresh

Comments 5

По сигнатуре SQL-процедуры неизвестно, что она может вернуть, это становится известно только во время выполнения процедуры.
Входные и выходные параметры хранимой процедуры можно посмотреть не вызывая её: скриншот.
Ну ладно, известно что может вернуть, но неизвестно, что она вернет на самом деле. Когда процедура вызывается по xDBC, сначала она передает метаданные, и вот в них уже точная информация о выходных данных. Здесь речь о том что список выходных параметров с точки зрения xDBC не обязан быть статичным.
Взглянув на сигнатуру хранимой процедуры, не вызывая её, я могу (должен) определить набор входных/выходных параметров.

Конкретно для Вашей ХП я вижу один входной параметр и ни одного выходного.
Отсюда я могу сделать вывод, что набор выходных полей будет либо динамическим либо пустым.
Так же, как по наличию синтаксиса args... в методе я могу догадаться о наличии неопределённого числа аргументов.

Но если окажется, что ХП вначале говорит, что вернёт три поля определённых типов, а в итоге возвращает два или двадцать полей неважно уже каких типов, то это будет вводить в заблуждение.
Но если окажется, что ХП вначале говорит, что вернёт три поля определённых типов, а в итоге возвращает два или двадцать полей неважно уже каких типов, то это будет вводить в заблуждение.
Согласен, некрасиво получится. Но протоколом xDBC такой сценарий предусмотрен. Вообще, суть немного в другом. XDBC позволяет делать динамические ХП, а Caché из коробки при NoSQL-доступе к данным — нет. И статья как раз о том, как обойти это ограничение.
Вообще, суть немного в другом. XDBC позволяет делать динамические ХП, а Caché из коробки при NoSQL-доступе к данным — нет. И статья как раз о том, как обойти это ограничение.
Мной изначально предполагалось, что Вы как-то учтёте в конкретном предложении статьи сделанное уточнение.
Sign up to leave a comment.