Предыдущая тема :: Следующая тема |
Автор |
Сообщение |
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), а накат сбросил кэш. | Подробностей не знаю, а для выяснения нужен исходный код. У меня тоже было как-то раз, что функционал не работал, но при этом выдавал правильный результат
Mourinjo пишет: | Это я потом соколиным глазом выявил. Уух из-за одной маленькой ошибки могут быть большие неприятности. После этого чувствуешь себя следователем ))
|
Вы правы, я тоже порой ловлю себя на мысли, что я детектив  |
|
 |
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 |
|
 |
|
|
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете голосовать в опросах
|
|