Кеширование вьюх. (Свойство CacheLookup для View)

[Logger]

Добрый день всем.

Коллеги, возможно ли штатно в аксапте (речь о 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 свойства

      CacheLookup         #Found
      CreateRecIdIndex    #Yes

импортнул обратно.


Кеширование по RecId заработало !

Интересно, что при импорте утилита сравнения не показала никаких отличий. Т.е. она не учитывала эти свойства. Также если не выставить

Цитата:

CreateRecIdIndex #Yes

то тоже кеширование не работает.

Другие индексы прописать невозможно, что в общем неудивительно, так как во вьюхе могут быть свои поля, которые называются совсем не так, как поля в индексе таблички.

Странно, все же почему во вьюхах штатно кеширования нет. Реально то движок есть и для RecId даже можно заставить его работать. Т.е. можно было бы в интерфейс привинтить возможность указания ключа кеширования (например как в RecordSortedList можно задавать ключа хранения / поиска). Было бы удобно.


А как в D365 c этим обстоят дела ?

[Logger]

Прикладываю вьюхи и джоб, которым тестировал.

[TasmanianDevil]

А вот ежели View на Query с типом UnionAll, где весьма вероятны совпадения RecId ?

[Logger]

Не пробовал. Вероятно приведет к неправильной работе.
Но тут надо думать головой, когда применяем инструменты.

[Vadik]

Цитата:

Сообщение от Logger

Коллеги, возможно ли штатно в аксапте (речь о 2012-й) кешировать вьюхи

А если абстрагироваться от версии, как Вы считаете должно было бы работать кэширование? У view же нет первичного или уникального ключа

[Logger]

Цитата:

Сообщение от Vadik

А если абстрагироваться от версии, как Вы считаете должно было бы работать кэширование? У view же нет первичного или уникального ключа

Думаю, что если по правильному делать, то надо было бы у вьюхи сделать подветку в AOT -
Caching keys

аналогичную уникальным индексам на табличке, где можно было бы указать набор кеширующих ключей и перечень полей вьюхи, из которых они состоят.

Сейчас как-то странно запроектировано. Разработчики ядра 2012-й судя по всему, порезвились от души и привинтили кеширование везде где только можно. Поэтому я очень удивился не найдя его во вьюхах и подумал что я чего-то не знаю. Если уж джоины табличек научили кешироваться, то вьюхи тем более надо было. Явно ведь кеширование джоинов делали, имея в виду радикальную нормализацию базы, из-за которого теперь вместо одного запроса к одной табличке, почти наверняка надо делать джоин.

Получается дурацкая ситуация - берем кверик, на основе которого сделана вьюха, используем его в запросе - отрабатывает кеширование, SQL не нагружается. Используем вьюху на основе этого кверика, использующую те же поля, которые кверик возвращает или их часть - все запросы летят в SQL. Лучше бы сделали наоборот. Дать программисту возможность настроить кеширование для вьюх, и забить на джоины. Это особенно актуально, потому что из-за нормализации базы многие вьюхи - это простые джоины, и если делать запрос без вьюхи, то кеширование работает.

Касательно отсутствия у вьюхи ключа, я подумал что в простом случае джоина можно было бы попробовать использовать ключ от таблички. Похожий подход использован в union Query. Там поля первого датасорса определяют набор полей, названия и типы для юниона. Здесь аналогично можно было бы сделать. Хотя, конечно, это полумера.

[gl00mie]

Возможно, причина, по которой в ядре не разрешено кэшировать записи View, в том, что для обычных таблиц у ядра есть механизмы отслеживания, когда кэши стали неактуальными, а View для ядра - это некая абстракция, можно сказать, черный ящик, и там такого механизма актуализации кэшей нет. К примеру, если отвлечься от идеи обновлять кэш View по изменению любой связанной таблицы, во View ведь может быть вычисляемое поле, которое лезет подзапросом в другие таблицы или смотрит на текущую фазу луны. Кэширование записей View с таким полем легко может привести к тому, что от кэша будет куда больше вреда, чем пользы. Думаю, из этих соображений на View и отключили кэширование средствами ядра.

[Logger]

Цитата:

Сообщение от gl00mie

Возможно, причина, по которой в ядре не разрешено кэшировать записи View, в том, что для обычных таблиц у ядра есть механизмы отслеживания, когда кэши стали неактуальными,...

Да, вероятно в этом и была причина почему они так сделали.

Хотя, я думаю что все же случай вычисляемых полей - не такой частый. Плюс всегда ведь можно написать в insert / update / delete табличек код

super();
flush TableName;

в параметрических табличках везде так пишут и никто не умер. А для обычных полей ядро легко может зависимость отследить, ведь когда Query меняешь, то ядро предупреждает что есть зависимые вьюхи и обновляет их. Так и тут.

Кстати, кеширование джоинов в связке с прямыми запросами к базе уже приводило к подобным проблемам - была где-то тема про кеширование запроса по джоину InventSum - InventDim. Т.е. джина уже выпустили из бутылки... Нет причин не делать кеширование вьюх, если сделали кеширование джоинов.

[Logger]

Всем спасибо за обсуждение. Самое главное, я понял что так и задумано, а не я чего-то недопонимаю.

[TasmanianDevil]

Кстати, о птичках ...
Кроме кэширования, есть скользкий момент на View, построенном на группировочном запросе. RecId в таком View ненулевой и идентичный для всех записей. О последствиях неосторожного и невнимательного использования таких View можете сами догадаться (например очень интересно будет вести себя метод reread() )...