Система кэширования

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

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

Вы можете полностью отключить механизм, указав в конфиге “useCache”:false.

Вы можете отключить использования кэширования для определенного запроса передав в параметры запроса “use_cache”=false (так сложилось, что в одном случае camelCase, а в другом snake_case).

Это параметр относится именно к запросу, а не к параметрам метода, то есть система его получает из r.rParams, а не из r.data.params, однако вы можете его передавать в параметрах метода, он автоматически будет перенесен в перенесен куда надо.

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

Еще не до конца реализовано

На уровне класса, после загрузки профайла, вы можете определить (например в переопределенном методе init) поле cache_max_length (в профайл: this.class_profile.cache_max_length) Оно определит максимальное кол-во строк может хранится в кэше для этого класса. Параметр есть, а механизм очистки сверх лимита (самых старых в кэше) еще не реализован. Также при доработке имеет смысл вынести cache_max_length в профайл в СУБД, то есть расширить структуру класса class_profile.

В настоящее время система не контролирует переполнение памяти. Нужно будет дописать контроль максимального указанного в конфигурации лимита по памяти и вычищать при необходимости более старые данные.