mirror of
https://github.com/zkldi/Tachi.git
synced 2026-09-26 00:47:57 +03:00
zk
e363bd2532
* docs: migrate from mkdocs to mdbook - Rename old mkdocs docs/ to old-docs/ for reference - Set up new docs/ with mdbook (book.toml + src/ tree) - Mirror full nav structure from mkdocs.yml into SUMMARY.md - Add Justfile-docs with docs-serve, docs-build, docs-check, docs-install recipes - Import Justfile-docs from root Justfile - Rewrite .github/workflows/docs.yml: build step uses taiki-e/install-action to install mdbook, split into separate build + deploy jobs, PR builds run the check step too * ci(docs): pin actions to SHAs, install mdbook via release binary * ci(docs): install mdbook from apt instead of curling a release binary * dev: replace mkdocs python stack with mdbook in dev image * ci(docs): apt only works on Debian; restore release binary install for Ubuntu CI * docs: fix duplicate file entries in SUMMARY.md * docs: remove docs-install recipe * docs: remove site-url from book.toml to fix asset loading * dev: install mdbook from upstream release binary, not Debian apt The Debian package (0.4.x+ds) strips bundled font assets, leaving the built site without fonts/fonts.css. Use the upstream tarball (same as CI) so the theme is complete. Handles x86_64 and aarch64. * docs: vendor mdbook tarballs in dev/mdbook/, install from there Dockerfile.dev uses COPY + tar to install the right arch at build time. CI extracts the x86_64 tarball directly from the checkout. No network access required for either — and no stripped-fonts Debian package. * fix: unwritten
44 lines
1.3 KiB
Markdown
44 lines
1.3 KiB
Markdown
# Search Implementation
|
|
|
|
Tachi's search implementation uses MongoDB's $text index. This breaks a query into words
|
|
and compares each of them to the provided text fields.
|
|
|
|
*****
|
|
|
|
## __textScore
|
|
|
|
For our code, we mutate the documents we want to return with a special field: `__textScore`.
|
|
|
|
This field declares how 'close' the provided query was to the $text fields in this document.
|
|
|
|
This is sometimes exposed in the API for sorting reasons.
|
|
|
|
!!! bug
|
|
MongoDB's $text matching algorithm isn't great for fuzzy matches - It doesn't
|
|
like song titles like 'A', as it thinks 'a' is an article, and doesn't match it properly as
|
|
a word.
|
|
|
|
!!! info
|
|
Why not regex for fuzzy matches?
|
|
|
|
Regex has performance issues on larger datasets and we
|
|
want to avoid it. Most regexes cannot use indexes, and therefore invoke a COLLSCAN, which
|
|
we want to avoid.
|
|
|
|
## User Searching
|
|
|
|
Searching users, on the other hand, has to use regex-based
|
|
searching.
|
|
|
|
The `$text` method attempts to break things up based on their
|
|
words, but that doesn't help with usernames, as they are all
|
|
too frequently `XxX_One_Long_Str1ng_xXx`.
|
|
|
|
Instead, we use a case insensitive regex - similar to SQL's
|
|
`LIKE`.
|
|
|
|
This means we do not have a `__textScore` property for this
|
|
search to sort on. Instead, we just constrict returns to
|
|
around 15, and have the user whittle their search down
|
|
better.
|