02.10.2018, 13:13 | #1 |
Участник
|
Кеширование вьюх. (Свойство CacheLookup для View)
Добрый день всем.
Коллеги, возможно ли штатно в аксапте (речь о 2012-й) кешировать вьюхи ? В целом в 2012-й версии кеширование очень продвинутое - вплоть до кеширования джоинов. Также поддерживается кеширование по любому уникальному ключу, что очень удобно. https://docs.microsoft.com/en-us/dyn...record-caching Про вьюхи в документации сказано как-то расплывчато. https://docs.microsoft.com/en-us/pre...869223(v=ax.60) Явно указано Цитата:
The properties that can be set for a View are listed below.
... CacheLookup Retrieves the record cache level for the table. Но явно не описано как можно было бы использовать кеширование. Кроме того в свойствах вьюхи поле CacheLookup задизейблено. Т.е. получается, что нельзя. Как-то это нелогично. Вьюхи используются практически везде. Строятся зачастую по Query, который является джоином табличек по уникальным ключам. При таком условии если мы делаем запрос через Query - то кеш отрабатывает. А если используем View основанный на Query - то нет. Т.е. увеличивается нагрузка на базу. Я попробовал хакнуть вьюху. Выгрузил в xpo задал в xpo свойства X++: CacheLookup #Found CreateRecIdIndex #Yes Кеширование по RecId заработало ! Интересно, что при импорте утилита сравнения не показала никаких отличий. Т.е. она не учитывала эти свойства. Также если не выставить Цитата:
CreateRecIdIndex #Yes
Другие индексы прописать невозможно, что в общем неудивительно, так как во вьюхе могут быть свои поля, которые называются совсем не так, как поля в индексе таблички. Странно, все же почему во вьюхах штатно кеширования нет. Реально то движок есть и для RecId даже можно заставить его работать. Т.е. можно было бы в интерфейс привинтить возможность указания ключа кеширования (например как в RecordSortedList можно задавать ключа хранения / поиска). Было бы удобно. А как в D365 c этим обстоят дела ? |
|
02.10.2018, 13:14 | #2 |
Участник
|
Прикладываю вьюхи и джоб, которым тестировал.
|
|
02.10.2018, 13:45 | #3 |
Мрачный тип
|
А вот ежели View на Query с типом UnionAll, где весьма вероятны совпадения RecId ?
__________________
Мы летаем, кружимся, нагоняем ужасы ... |
|
|
За это сообщение автора поблагодарили: Logger (3). |
02.10.2018, 13:56 | #4 |
Участник
|
Не пробовал. Вероятно приведет к неправильной работе.
Но тут надо думать головой, когда применяем инструменты. |
|
02.10.2018, 14:00 | #5 |
Модератор
|
А если абстрагироваться от версии, как Вы считаете должно было бы работать кэширование? У view же нет первичного или уникального ключа
__________________
-ТСЯ или -ТЬСЯ ? |
|
|
За это сообщение автора поблагодарили: Logger (3). |
02.10.2018, 14:07 | #6 |
Участник
|
Возможно, причина, по которой в ядре не разрешено кэшировать записи View, в том, что для обычных таблиц у ядра есть механизмы отслеживания, когда кэши стали неактуальными, а View для ядра - это некая абстракция, можно сказать, черный ящик, и там такого механизма актуализации кэшей нет. К примеру, если отвлечься от идеи обновлять кэш View по изменению любой связанной таблицы, во View ведь может быть вычисляемое поле, которое лезет подзапросом в другие таблицы или смотрит на текущую фазу луны. Кэширование записей View с таким полем легко может привести к тому, что от кэша будет куда больше вреда, чем пользы. Думаю, из этих соображений на View и отключили кэширование средствами ядра.
|
|
|
За это сообщение автора поблагодарили: Logger (3). |
02.10.2018, 15:00 | #7 |
Участник
|
Цитата:
Caching keys аналогичную уникальным индексам на табличке, где можно было бы указать набор кеширующих ключей и перечень полей вьюхи, из которых они состоят. Сейчас как-то странно запроектировано. Разработчики ядра 2012-й судя по всему, порезвились от души и привинтили кеширование везде где только можно. Поэтому я очень удивился не найдя его во вьюхах и подумал что я чего-то не знаю. Если уж джоины табличек научили кешироваться, то вьюхи тем более надо было. Явно ведь кеширование джоинов делали, имея в виду радикальную нормализацию базы, из-за которого теперь вместо одного запроса к одной табличке, почти наверняка надо делать джоин. Получается дурацкая ситуация - берем кверик, на основе которого сделана вьюха, используем его в запросе - отрабатывает кеширование, SQL не нагружается. Используем вьюху на основе этого кверика, использующую те же поля, которые кверик возвращает или их часть - все запросы летят в SQL. Лучше бы сделали наоборот. Дать программисту возможность настроить кеширование для вьюх, и забить на джоины. Это особенно актуально, потому что из-за нормализации базы многие вьюхи - это простые джоины, и если делать запрос без вьюхи, то кеширование работает. Касательно отсутствия у вьюхи ключа, я подумал что в простом случае джоина можно было бы попробовать использовать ключ от таблички. Похожий подход использован в union Query. Там поля первого датасорса определяют набор полей, названия и типы для юниона. Здесь аналогично можно было бы сделать. Хотя, конечно, это полумера. Последний раз редактировалось Logger; 02.10.2018 в 15:19. |
|
02.10.2018, 15:07 | #8 |
Участник
|
Цитата:
Хотя, я думаю что все же случай вычисляемых полей - не такой частый. Плюс всегда ведь можно написать в insert / update / delete табличек код X++: super(); flush TableName; Кстати, кеширование джоинов в связке с прямыми запросами к базе уже приводило к подобным проблемам - была где-то тема про кеширование запроса по джоину InventSum - InventDim. Т.е. джина уже выпустили из бутылки... Нет причин не делать кеширование вьюх, если сделали кеширование джоинов. |
|
02.10.2018, 15:08 | #9 |
Участник
|
Всем спасибо за обсуждение. Самое главное, я понял что так и задумано, а не я чего-то недопонимаю.
|
|
30.11.2018, 09:26 | #10 |
Мрачный тип
|
Кстати, о птичках ...
Кроме кэширования, есть скользкий момент на View, построенном на группировочном запросе. RecId в таком View ненулевой и идентичный для всех записей. О последствиях неосторожного и невнимательного использования таких View можете сами догадаться (например очень интересно будет вести себя метод reread() )...
__________________
Мы летаем, кружимся, нагоняем ужасы ... |
|
Теги |
cache, cache lookup, query, view |
|
|