Learn more about these different git repos.
Other Git URLs
As the policy becomes larger and more complex, a test is possibly called multiple times, but actually, it is only needed once, as it is in a single API call, and so in a single DB transaction.
Adding a cache mechanism may speed up the call more or less.
A simple implementation is: caching the result into policy_data with key: __sth, but maybe we could do more.
policy_data
__sth
Open the ticket for discussion here.
Caching can be tricky to get right, and getting it wrong can lead to very difficult-to-debug issues.
I think this is worth pursuing, but we should be very careful and systematic. I don't think there is an immediate rush.
Metadata Update from @mikem: - Custom field Size adjusted to None
We should consider the scope of caching.
First, we should never cache results across separate hub calls. That would violate stateless assumptions in the hub code, and likely result in stale cache entries.
However, we might want to be more fine grained that that. A given call can involve multiple policy checks, and we might want this cache to be limited to a given policy run (because data could change between two different policy runs).
The issue that could be caused by caching is the use of multicall, when the cache's lifecycle is out of check_policy() (it shouldn't happen when the cache is a item of policy_data, unless policy_get_*() is used out of check_policy() )
multicall
check_policy()
policy_get_*()
Log in to comment on this ticket.