This get+conditional set is also slightly prone to data races, but
doesn't seem to be harmful as of now.
Rationale:
- To enable recorder one must first send a request, so this should be
set long before.
- While enabling we can accidentally clear cache for another worker by
invalidating it, but that is kind of acceptable behaviour. We ONLY set
it to False when `None` is received from Redis. Local invalidations
remove it completely.
Picking 1024 keys assuming 4kb avg size. In practice most things are
smaller so 1024 should be good enough!
This will likely only affect multitenant deploy with many sites.
If I have to hazard a guess, 99% API calls are not server scripts, then
why check it first and pay the costs?
This PR first checks if method is a real method in python code and if
it's not found then only attempts to fetch it from server script map.
I'll revert this if I can bring the costs in acceptable limits with
client-side caching.
These are deletes that aren't user triggered and these documents are
typically never "linked" somewhere else. So skip all expensive link /
dynamic link checks.
Currently one test runner takes significantly longer than another. This
is entirely due to test_commands.py which needs to create new site and
do backup/restore tests etc. All of which are far far slower than other
tests.
ERPNext updates defaults everytime settings are changed but there's no
need to do it when value itself hasn't changed.
IDK if there are things that depend on this weird behaviour, there
shouldn't be any **ideally**.
Feel free to revert if it breaks.
I don't like test fixtures at all but breaking this is so pointless.
I can't even re-run ERPNext tests!
People should overtime stop relying on hardcoded fixtures and write
utils to generate them at runtime in tests. I've migrated tons of tests
this way during my time in ERPNext team and those tests are far more
reliable than hardcoded ones.
For doctype/user specific cache eviction, no need to remove site_cache.
Rationale:
- Site cache is worker specific, so this eviction doesn't help much.
- Anything that might need to be evicted from site cache should be
manually cleared or use a TTL.
Maybe we can just replace all of site_cache usage with
https://github.com/frappe/frappe/pull/28992 once it's stable.
