* 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
1.3 KiB
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.