29.02.2024, 15:44 | #1 |
Участник
|
Багофича qbds.cacheAddMethod() для _updateOnWrite = true
Привет всем.
Заметил особенность кеширования дисплей методов для параметра _updateOnWrite = true метода cacheAddMethod(). Обновление значений дисплей методов идет при вызове super() в табличном методе update. (А лучше бы шло после отработки update.) Последствия : Если есть форма, шапка - строки (например SalesTable c двумя датасорсами - SalesTable_ds и SalesLine_ds) На шапке есть дисплей методы отображающие агрегированные суммы из строк. Меняем в шапке скидку, это влияет на сумму по строке. Но при сохранении шапки, дисплей методы шапки обновляются до того как обновятся строки (обновление строк стоит после super() в методе update шапки). - Т.е. дисплей методы показывают неактуальные, старые значения сумм по строкам. Нужно сохранить шапку повторно, и только тогда обновятся дисплей методы. Для таких ситуаций (весьма часто встречающихся)) параметр _updateOnWrite = true бесполезен. Приходится его явно ставить в false и на write датасорса вызывать для каждого дисплей метода cacheCalculateMethod Либо скопом один раз вызывать salesTable.executeCachedDisplayMethods() (Ax 2012 R3) |
|
|
За это сообщение автора поблагодарили: gl00mie (10). |
29.02.2024, 16:39 | #2 |
Участник
|
С другой стороны, а где еще ядру пересчитывать закэшированные display-методы, как не внутри super() в update()? Если бы даже ядро обновляло их после update(), то можно было бы засунуть бизнес-логику в пост-обработчики, и тогда тоже пересчитанные вслед за update() значения могли бы оказаться неактуальными.
|
|
29.02.2024, 17:30 | #3 |
Участник
|
|
|
01.03.2024, 11:36 | #4 |
Участник
|
Что еще плохо у такого поведения
1. Дисплей методы отрабатывают при открытой транзакции,. Т. Е показывают незафиксированные данные. 2. Длительность транзакции увеличивается на время отработки дисплеев, со всеми налагаемыми блокировками . Всего этого можно было бы избежать, если бы дисплей методы рассчитывались позже, после отработки update и после закрытия транзакции. |
|
01.03.2024, 11:50 | #5 |
Участник
|
В идеале update вообще не должен вызывать процедуру пересчёта кэша, он должен только устанавливать признак того что кэш устарел. А процедура пересчёт должна срабатывать при первом обращении к такому устаревшему кэшу
|
|
01.03.2024, 16:43 | #6 |
Участник
|
Ну выход есть. Можно указывать _updateOnWrite = false и явно ручками инициировать обновление кеша.
А в текущем виде значение _updateOnWrite = true часто бесполезно. Но смысл в нем есть. Есть сценарии когда он может быть полезен. Особенно если бы обновление шло после update. |
|
Теги |
cacheaddmethod, updateonwrite, баг, кеш |
|
Похожие темы | ||||
Тема | Ответов | |||
Как узнать, что форма открыта через "Перейти к форме основной таблицы"? | 15 | |||
ошибка в AIF | 14 | |||
Сортировка в Report | 8 | |||
Очередная бороьба с Query() (DAX2009) | 3 | |||
NoExistsJoin и addRange | 15 |
Опции темы | Поиск в этой теме |
Опции просмотра | |
|