- Kinda confuses query planner (idk why it's not smart enough to
understand but there are probably edge cases where it can't be done)
- `null != null` and `'' != null` both yield `null` which is falsy and
won't be shown in results.
Alternate fix to https://github.com/frappe/frappe/pull/21817
* fix: procure db config from single authority
ensures that configuration is uniformely procured from local.conf
instead of making use of hard to audit multilevel fallback logic
Implementation Note:
- `get_db(host, port, user, password)` was stripped of any optional
argument and therefrom all errors where fixed.
- All occurances of `grep 'frappe.db.db_'` where changed to
`frappe.conf.db_`
* fix: revert unnecessary breaking changes
We eagerly fetch shared documents for ANY `get_list` query, even when
user has full read acess doctype, where it's moot to consider adding
shared document as separately.
This eliminates one entire db call from get_list and in most cases
get_list will translate to single DB call, hence probably worth the
additional complexity.
Attempt to normalize query by removing "variables"
This gives a different view of similar duplicate queries.
These two are distinct queries:
```sql
select * from user where name = 'x'
select * from user where name = 'z'
```
But their "normalized" form would be same:
```sql
select * from user where name = ?
```
This helps highlight queries ran in loop which might not register as
duplicate but are possibly "duplicate".
* feat: Custom naming series parser via hooks
* chore: use assignment operatot
Co-authored-by: Ankush Menat <ankushmenat@gmail.com>
* test: Unit test for custom parser
* test: Unit test for custom parser
---------
Co-authored-by: Ankush Menat <ankushmenat@gmail.com>
- Build version wasn't correctly computed since v14 update of build
system. This makes client side cache useless.
- We clear cache assuming rapid reloads,but opening new tab also does
that. This makes the cache effectively useless for most users.
This avoids having to manipulate config files in brittle bash
entrypoints that need to react to dynamic service discovery.
This significantly improves the operability of various bench sites.
By processing `EXPLAIN` of queries in background after recording is
completed, the overhead reduces significantly and hence can be used
"more" in production environment too.
* perf: preload more modules
- bleach is used frequently for sanitization
- File gets imported anytime a private file is viewed. Indirect import
of PIL is costly in each worker.
* test: warm up perf test
`frappe.local.request` was not cleared between tests, which would not be a problem if all tests did set it to another Request object. But, some tests directly fetch the response content using get_response_content without first setting the frappe.local.request object (using set_request).
This test code never actually tested the behaviour for two reasons:
- first, the page had an error which meant that a 500 Error page was returned (because `path` is not a string)
- second, every page contains the string "400" because it's contained in some of the icons.svg icons!
I also found a minor related bug in static_page.py, allowing people to download PYC files (pycache)
w/ explicit check for singles
This shouldn't have any performance impact as last function call only
happens if we THINK it's single doctype. use set_single_value to avoid
that extra function call.
test: change code to adapt to new werkzeug client
fix: avoid setting charset
utf8 is default and assumed now by werkzeug, setting this manually is
deprecated.
fix: use string instead of bytes for setting headers
DeprecationWarning: Passing bytes as a header value is deprecated and will not be supported in Werkzeug 3.0.
12:23:34 web.1 | response.headers["X-Page-Name"] = path.encode("ascii", errors="xmlcharrefreplace")
