CftClub.ru
Клуб специалистов ЦФТ-Банк

set_par и get_par

 
Ответить на тему    Клуб специалистов ЦФТ-Банк (IBSO) -> Уроки ЦФТ-Банк для начинающих
Предыдущая тема :: Следующая тема  
Автор Сообщение
Mourinjo
Участник со стажем


Вступление в Клуб: 21.12.2010
СообщениеЧт Июн 01, 2017 12:51   set_par и get_par Ответить с цитатой
Полезность: Нет оценки
Добрый день, уважаемые гуру ЦФТ! Вопрос по процедуркам [STR].SET_PAR и [STR].GET_PAR. Я так понял, что процедурой SET_PAR мы записываем в строковый буфер P_ADDS ключ и его значение, а процедурой GET_PAR мы получаем по этому же ключу его значение (некая аналогия с сеттерами и геттерами из ООП языков типа Java и ini файлами в Delphi).
Пример:
[STR].set_par(p_adds, 'CLASS', v_dog%class); -- Вызов в операции А
[STR].get_par(p_adds, 'CLASS', v_class_dog); -- Вызов в операции Б

Они очень удобны когда пишешь бизнес-операции, чтобы записывать как ключ (код из справочника типов счетов) скажем ссылку на счет, а в операции GET_REQ_CLIENT получать его при помощь get_par. У меня возник вопрос: set_par и get_par работают в рамках одной сессии или другая сессия может извлекать get_par по некоему ключу, который использовался в первой сессии ? Каков риск использования общих ключей в разных бизнес-операциях. Каков жизненный цикл такого буфера P_ADDS ? Есть ли подводные камни когда кэшируются переменные в буфере?
Эмиралька
Эксперт


Вступление в Клуб: 09.11.2015
СообщениеЧт Июн 01, 2017 13:41   Re: set_par и get_par Ответить с цитатой
Полезность: Нет оценки
Mourinjo пишет:
Добрый день, уважаемые гуру ЦФТ! Вопрос по процедуркам [STR].SET_PAR и [STR].GET_PAR. Я так понял, что процедурой SET_PAR мы записываем в строковый буфер P_ADDS ключ и его значение, а процедурой GET_PAR мы получаем по этому же ключу его значение (некая аналогия с сеттерами и геттерами из ООП языков типа Java и ini файлами в Delphi).
Пример:
[STR].set_par(p_adds, 'CLASS', v_dog%class); -- Вызов в операции А
[STR].get_par(p_adds, 'CLASS', v_class_dog); -- Вызов в операции Б

Они очень удобны когда пишешь бизнес-операции, чтобы записывать как ключ (код из справочника типов счетов) скажем ссылку на счет, а в операции GET_REQ_CLIENT получать его при помощь get_par. У меня возник вопрос: set_par и get_par работают в рамках одной сессии или другая сессия может извлекать get_par по некоему ключу, который использовался в первой сессии ? Каков риск использования общих ключей в разных бизнес-операциях. Каков жизненный цикл такого буфера P_ADDS ? Есть ли подводные камни когда кэшируются переменные в буфере?


p_adds - это переменная, объявленная в данной сессии. Её прошлое и будущее определяются только разработчиком, - захочет, сохранит, не захочет - выкинет.
get_par и set_par - это всего лишь функции-трансляторы, разбирающие строку p_adds и возвращающие значение указанной составляющей (get), если оно в строке p_adds есть, или наоборот, собирающие строку p_adds на основании прочих параметров (set)

Ни про какие ini-файлы речи не идёт!

set условно можно представить как p_adds := p_adds || ';CLASS='||v_dog%class;
а get как v_class_dog := substr(p_adds, instr(p_adds, ';CLASS=')+, ну и тут третий параметр);
Mourinjo
Участник со стажем


Вступление в Клуб: 21.12.2010
СообщениеЧт Июн 01, 2017 14:25    Ответить с цитатой
Полезность: Нет оценки
Да вы правы, ini файлы тут нипричем, но есть некая схожесть: запись и чтение значений по ключу. Получается буфер P_ADDS живет в рамках сессии пользователя как глобальная переменная ? Просто я хочу понять как оно работает. Просто был прикол: было сделано расширение для дистрибутивной операции [DOCUMENT].GET_REQ_CLIENT, и в ней нехороший программист написал свой код и использовал переменную P_ADDS, хотя надо было использовать дистрибутивную переменную P#ADDS (отличие в одном символе _ вместо #). Все благополучно работало 2 года, пока не был произведен накат с тестовой среды на живую, и пошли ошибки (видимо P_ADDS закэшировался под P#ADDS), а накат сбросил кэш. Это я потом соколиным глазом выявил. Уух из-за одной маленькой ошибки могут быть большие неприятности. После этого чувствуешь себя следователем ))
vtar
Эксперт


Вступление в Клуб: 20.03.2009
СообщениеЧт Июн 01, 2017 17:49    Ответить с цитатой
Полезность: Нет оценки
Mourinjo пишет:
Да вы правы, ini файлы тут нипричем, но есть некая схожесть: запись и чтение значений по ключу. Получается буфер P_ADDS живет в рамках сессии пользователя как глобальная переменная ?


нет. Это параметр. Если его передает разработчик при вызове операции из операции то он передается. Если нет то нет.

То есть это не универсальный способ передачи. Где ЦФТ передает его по цепочке вызовов, там это работает.
Эмиралька
Эксперт


Вступление в Клуб: 09.11.2015
СообщениеПт Июн 02, 2017 05:37    Ответить с цитатой
Полезность: Нет оценки
Mourinjo пишет:
Получается буфер P_ADDS живет в рамках сессии пользователя как глобальная переменная ?

Нет, это не глобальная переменная.
Обратите внимание как это сделано в отчётности:
есть переменная, объявленная в операции запуска, например, INTEGR_FORMS.F_133, в неё при запуске записываются параметры экранной формы, например, [STR].Set_Par(vInfo, 'V_TYPE_PRC' , V_TYPE_PRC.[0]);
После этого переменная записывается в таблицу базы данных z#reps_params, и идентификатор этой записи шляется по всем операциям расчёта. В операции расчёта по идентификатору из таблицы получается строка, из строки с помощью [STR].get_par добываются параметры экранной формы и используются при расчёте.
Ни о какой глобальности речи не идёт, да и идти не может.
Mourinjo пишет:
было сделано расширение для дистрибутивной операции [DOCUMENT].GET_REQ_CLIENT, и в ней нехороший программист написал свой код и использовал переменную P_ADDS, хотя надо было использовать дистрибутивную переменную P#ADDS (отличие в одном символе _ вместо #). Все благополучно работало 2 года, пока не был произведен накат с тестовой среды на живую, и пошли ошибки (видимо P_ADDS закэшировался под P#ADDS), а накат сбросил кэш.
Подробностей не знаю, а для выяснения нужен исходный код. У меня тоже было как-то раз, что функционал не работал, но при этом выдавал правильный результат Smile

Mourinjo пишет:
Это я потом соколиным глазом выявил. Уух из-за одной маленькой ошибки могут быть большие неприятности. После этого чувствуешь себя следователем ))

Вы правы, я тоже порой ловлю себя на мысли, что я детектив Cool
Gobur
Профи


Вступление в Клуб: 06.11.2012
СообщениеПт Июн 02, 2017 09:19    Ответить с цитатой
Полезность: Нет оценки
Бывает , что ЦФТ сами не знают , на каком этапе работы параметры могут затереться.
Я помню, когда вводили признак оплаты из картотеки , то тоже пытались делать через P_ADDS . Но на одном из этапов этот параметр то ли чистился, то ли удалялся. В итогев ЦФТ написали функцию.
Mourinjo
Участник со стажем


Вступление в Клуб: 21.12.2010
СообщениеПт Июн 02, 2017 11:49    Ответить с цитатой
Полезность: Нет оценки
Цитата:

Gobur
Бывает , что ЦФТ сами не знают , на каком этапе работы параметры могут затереться.
Я помню, когда вводили признак оплаты из картотеки , то тоже пытались делать через P_ADDS . Но на одном из этапов этот параметр то ли чистился, то ли удалялся. В итогев ЦФТ написали функцию.



Кстати да, слетело у нас (затерся P_ADDS) после того, когда была миграция с 11 на 12 Oracle
Показать сообщения:   
Ответить на тему    Клуб специалистов ЦФТ-Банк (IBSO) -> Уроки ЦФТ-Банк для начинающих Часовой пояс: GMT + 3
Страница 1 из 1

 
Перейти:  
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Рейтинг@Mail.ru