-
-
Notifications
You must be signed in to change notification settings - Fork 784
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[v1.0.0 nightly] - Search misses "easy" hits when there are intervening words or the order is changed #2325
Comments
Almost forgot: this is using an SQLite docker compose stack (separate front and backend, not Omni) |
If I’m wrong about how fuzzy search is supposed to work in current mealie nightly, and this “bug” is actually a Feature Request, then this might be something that I could tackle. I just wouldn’t quite know how to hook the backend method I write up to the frontend. If it’s a FR, I would envision using a TheFuzz (aka FuzzyWuzzy) or RapidFuzz Levenshtein distance token_set_ratio against a (maybe pre-processed and updated whenever entry changed) FTS5 virtual table of the recipes. |
I implemented the current search, so let me shed some light on this. Search right now is not fuzzy and basically a "case-insensitive regex" like you describe. Main reason for this is that the old way of doing this (retrieve all recipes and filter client-side) was really bad and would have been WAY worse for a setup like yours, so the main goal here was to get something working that does the job at all This could definitely improved, but yeah that would be a feature request. If you want to implement it you have to keep in mind that the solution has to support both sqlite and postgres. This was a big showstopper because it means you cannot just simply implement it once using FTS5 It would maybe make sense to split this into two different features, since one of them is easier implement than the others:
I dont quite understand why that matters. Ideally the new solution should just be a drop-in replacement for the old one with neither input parameters nor output formatting changing |
OK, got it, and thanks for your answer. And thanks for implementing server-side search! Client-side search would indeed be quite painful in my use case. I assumed fuzzy search was implemented b/c I saw it in a v1.0.0 release note and it’s on the nightly intro page. Good point about postgres cross-compatability. I’m not so familiar with postgres and don’t have a working install of that db backend, but will do some digging. Levenshtein and trigram extensions seem to be implemented in both sqlite and postgres, so I would start looking there. Yes, you’re completely right that the solution should be seamless with the old. I’m not very familiar with the mealie internal codebase/API. If you point me to the location of the relevant search function, then I’ll take a look. |
Sure, it's this function here and that is pretty much all there is to it right now Feel free to contact me on the discord server, if you have any more questions ...Also that intro page should probably be changed if it still claims to have this. This was part of 1.0.0 at some point, but only done client-side |
I just made Feature Request #2335 with two proposed solutions. One of them yours which makes a lot of sense, and the other a bit crazy but surprisingly feasible (IMHO). I'm not well versed in Discord, so always get lost in the non-threaded flow of the channels. Sorry to always be posting in the GitHub threads. |
First Check
What is the issue you are experiencing?
I have a pretty large recipe database (6'000 or so) and have started noticing that search in the nightly release is not returning "easy" hits. It seems almost like search is not able to skip intervening words. For example, I have a recipe (json below) for "Pinto Bean, Beet, and Bulgur Burgers". Searching for "bulgur burger" or "pinto bean" or other combinations of words right next to each other in the recipe text/title/etc returns the recipe. But many other "easy" searches with intervening words or with the words reversed do not. For example, none of the following return the recipe:
I thought that search was supposed to be robust to these kinds of simple permutations? It's almost like search is omitting skip words and punctuation (e.g. "and" or commas are not required) but otherwise search is operating like case-insensitive regex. But not exactly, because a few skipped word searches do work, like “bean burger”
Deployment
Docker (Linux)
Deployment Details
No response
The text was updated successfully, but these errors were encountered: