Not all single doctypes are settings, so this is better. Implicit
caching is fine, same is done for `db` APIs on singles. We *should* aim
for 100% correctness of caching implementation, especially for singles.
Thanks to @netchampfaris for the suggestion.
* feat: get_settings
get_cached_value doesn't work well with singles because you either need
to pass `None` or repeat doctype name... both are awekward and easy to
shoot yourself in foot with.
* refactor: Use cached settings
This feels overengineered and it kinda is, but other efforts to
inroduce sequential naming/UUID naming haven't been that fruitful
either.
10 character random "hash" i now changed to.
1. first character - last character in UUID4 ID of request/job
2. three characters - derived from current timestamp.
4. 6 characters - random data.
This satisfies all three requirements:
1. Readers - temporal locality should result in spatial locality on disk. (fewer pages accessed)
2. Single writer - temporal locality should result in spatial locality. (fewer dirty pages)
3. Multiple writers - temporal locality should NOT result in spatial locality. (less lock contention)
Mostly concludes https://github.com/frappe/frappe/pull/25309 and https://github.com/frappe/frappe/pull/28349
Rough probabiliy numbers
Assumptions:
- Unique per worker prefix - 16 (uuid's base16 version)
- Rough time spent generating names - 10% of request (very very conservative estimate)
Probability(collision) = P(at least one prefix collision) * P(time collision)
Probability(collision) = (1 - p(all different)) * 10%
Probability(collision) = (1 - (16! / 16-N! )/ 16^N ) * 10%
| N (concurrency) | Probability(collision) |
| 1 | 0.0% |
| 2 | 0.6% |
| 3 | 1.8% |
| 4 | 3.3% |
| 5 | 5.0% |
| 6 | 6.6% |
| 7 | 7.9% |
| 8 | 8.8% |
Because of large common prefix hash naming becomes "too sequential" when
doing a lot of concurrent writes.
I don't know a good tradeoff between both use cases:
1. Lots of reads - prefers large shared prefix.
2. Lots of writes - prefers small shared prefix.
But as of now this punishes writes too badly in form of excessive
locking. Until a better fix is found, it's better to keep it prefix free.
---
A better fix would be a tradeoff of between these two:
1. Reads - temporal locality should result in spatial locality on disk.
2. Writes - temporal locality should NOT result in spatial locality.
temporal locality = data inserted around same time
spatial locality = data sits next to each other in DB pages.
This can be achieved by adding a small request/job specific part to
prefix so each concurrent request has it's own different locality when
writing data.
* fix: autoincr status per doctype
closes https://github.com/frappe/frappe/issues/21386
* chore: Check autoincremented on the database currently being used.
* refactor: Styling and space fix
---------
Co-authored-by: Athul Cyriac Ajay <athul8720@gmail.com>
* 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>
* feat: configurable amendment naming
* patch: set default amend naming
* chore: linters and document filter
* test: amended document naming
* refactor: use set_single_value
* chore: typo, fix copy
* fix(UX): move action button below table
* refactor: Series Counter -> Default Naming
The behaviour in this PR doesn't necessarily mean to apply naming series
it can be:
- Naming Series
- hash
- Naming Rule
- Some code
So the name was misleading.
---------
Co-authored-by: Ankush Menat <ankush@frappe.io>
When migrating base doctypes we need to insert docfield which triggers
document naming rule code and document naming rule doesn't yet exists
cause that's what we are trying to migrate.
Fix: skip naming rule on bootstrapped doctypes.
This has never worked since 2016... which can mean two things:
- No one really uses this.
- If I fix this now suddenly people will find different behaviour in
naming because `name_case` is selected in some doctypes (but never
tested)
refactor: clean up code to py39+ supported syntax
- f-strings instead of format
- latest typing support instead of pre 3.9 TitleCase
- remove UTF-8 declarations.
- many more changes
Powered by https://github.com/asottile/pyupgrade/ + manual cleanups
Converted all possible usages of re.* that weren't compiling the regex
separately and re-using it. Separated out the compiled patterns as
global variables. Repetitive patterns could be made DRY-er.
Would be nicer to have all regexes in a single module so that we could
re-use better, keep track of outdated, and keep checks for possible
reDos' etc
