09.06.2017, 16:30 | #1 |
Участник
|
таблица unitOfMeasureConversionCache (AX 2012 R3)
подскажите пожалуйста, почему таблица unitOfMeasureConversionCache не временная?
|
|
12.06.2017, 09:15 | #2 |
NavAx
|
По той же причине, по какой LedgerTransAccountTmp не временная.
__________________
Isn't it nice when things just work? |
|
13.06.2017, 14:03 | #3 |
Участник
|
|
|
13.06.2017, 18:51 | #4 |
Banned
|
Цитата:
Сбрасывает связанный к изменению кэш. В принципе практически оптимальное решение для подобного кэширования. И это не вычисление в контексте процесса и аоса. |
|
14.06.2017, 02:11 | #5 |
NavAx
|
Он самый. Некоторые места в коде overengineered настолько, что смысл происходящего начинает ускользать. И наименования объектов лишь добавляют мистики.
А что там такого тяжелого происходит, чтобы кэширование в постоянную таблицу себя оправдывало?
__________________
Isn't it nice when things just work? Последний раз редактировалось macklakov; 14.06.2017 в 02:24. |
|
14.06.2017, 11:24 | #6 |
Участник
|
Цитата:
В случае настройки юнит конвершна через базовый юнит вообще несколько раз приходится лукапить. А так в кэше уже есть четкий фактор преобразования, бери и пользуйся. А пересчитывать его имеет смысл только если кто-то меняет сам конвершн. Оттого и постоянная таблица. |
|
|
За это сообщение автора поблагодарили: Vadik (1), ax_mct (3). |
19.06.2017, 14:21 | #7 |
Участник
|
я почему спросил: в таблице UnitOfMeasureConversion в методах insert, update, delete
происходит чистка кэша: UnitOfMeasureConversionCache::flushOnConversionChanged(this.FromUnitOfMeasure, this.ToUnitOfMeasure, this.Product); по моим наблюдениям она всегда пуста (я о UnitOfMeasureConversionCache). у нас есть надстройка для портовой логистики, этот функционал очень часто дергает UnitOfMeasureConversion. из за этого происходят deadlock на delete UnitOfMeasureConversionCache. я пока убрал эту чистку и таблица UnitOfMeasureConversionCache начала расти, но не сильно, в унисон с UnitOfMeasureConversion. и кстати конвершн стал быстрее. но что я еще заметил - расчет происходит быстрее поиска готового кэша. теперь я не ищу расчет в кэше, а делаю его каждый раз: в партнерском классе, наследнике от UnitOfMeasureConverter_Product сделал override findConversion(), таблицу UnitOfMeasureConversionCache я стал использовать как временную. пока полет нормальный. Последний раз редактировалось AnGor; 19.06.2017 в 14:25. |
|
|
За это сообщение автора поблагодарили: macklakov (5). |
|
Опции темы | Поиск в этой теме |
Опции просмотра | |
|