This makes cache implementation uniform for all methods on db API. It's
weird that this specific method was caching in redis, which defies
expectations.
* fix: reduce bulk insert batch size
Back when this feature was added it used to lazily evaluate the input.
Now the iterator is consumed upfront so large batch sizes == huge memory usage.
* perf: bring back iterator for bulk_insert
Bulk insert used to support iterator for consuming arbitrarily large
amount of data and inserting it. Since child table support was added, it
can't do it anymore because that requires collecting values.
This change now brings back iterators by batching input iterator (by
default 1000) documents.
This is almost as good as original change from design POV. Performance
is still meh for flat documents.
* feat: mysqlclient
* fix: update error attrs
* fix: decode mogrified query to unicode
* fix: do some cleanup
* chore: disable cleanup for now
* fix: remove unnecessary call to as_unicode
* test: skip perf test for now
* fix: fallback to empty str
* fix: unbuffered cursor support
* fix: update converters and other changes
* fix: add cleanup back
* perf: improve timedelta converter
* fix: dont attempt to run query when explain flag is set
* test: cleanup tests
* chore: remove commented code
* perf: store conf as local var
* chore: ensure sequence
---------
Co-authored-by: Ankush Menat <ankush@frappe.io>
* perf: Reduce penalty for lack of redis connection
If redis isn't running than this client cache is slower than default
implementation because of the extra locking overhead.
* test: update perf redis counts
* perf: cache table columns in client-cache
* fix: race condition on cache-client_cache init
Rare but apparant in synthetic benchmarks.
Cache is set but client cache is still being initialized then request
will fail.
* perf: Don't run notifications when loading document
WHAT?
* fix: use cached doc to repopulate
* perf: reduce get_meta calls
Unnecessary overhead and need to disable this everytime I want to get
realistic performance numbers out.
All the performance affecting toggles should be directly controlled by
just `developer_mode` alone.
If filters are list or dict then they aren't hashable, there was little
reason to do this IMO.
If something is indeed cacheable then where is the eviction for it?
simple k:v is only thing we can realistically cache here.
* feat: Add deprecation_dumpster.py file
* docs: add jovial and jocose docstring for frappe/deprecation_dumpster.py
* refactor: fill the dumpster with its own kind
* refactor: move to the deprecation dumpster
* chore: color coding class
* fix: only check import error when import errors
* fix: Fixes mariadb orm to return list instead of tuple as the typisation suggests it
* fix: inverted fix for pg: Expect tuple as data_type for _transform_result
* fix: Fixed failing upstream spec due to data_type change
- Events like doc.save and doc.submit need to be atomic
- Document hooks can make it not so atomic.
This is extending server script behaviour where server script hooks are
not allowed to commit/rollback.
