You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Not sure if this a total edge case or intended functionality, but anyway: when searching any "male" namespace tag, LRR returns all "female" results as well. E.g. searching for let's say... "male:furry" will also return all "female:furry". This can be avoided by adding a $ and making it an exact search, but it's a little weird and fuzzier than how I've come to expect tag searching to usually work.
Anyway, just letting you know!
The text was updated successfully, but these errors were encountered:
👋 As things are, I'd say it's kinda intended?
The search engine is fuzzy by definition unless you make it an exact search with quotes or $.
I didn't really look in detail as to how other implementations do it so it seemed logical at the time. 🤔
Making it so that the namespace part of a search must be an exact match is a reasonable enhancement request, I'd say.
#555 fixes this: tag searches are now required to be exact and separated by commas.
I plan to eventually bring wildcard support back again if people request it. ✌️
small addendum: I added wildcard support back sooner than planned, but did take this into account.
tag searches will be fully wildcard, namespace:tag searches will only be wildcarded at the end (namespace stays intact).
You can use *namespace:tag if you want the old behavior for some weird reason.
(Running LRR 0.7.7 in Docker)
Not sure if this a total edge case or intended functionality, but anyway: when searching any "male" namespace tag, LRR returns all "female" results as well. E.g. searching for let's say... "male:furry" will also return all "female:furry". This can be avoided by adding a $ and making it an exact search, but it's a little weird and fuzzier than how I've come to expect tag searching to usually work.
Anyway, just letting you know!
The text was updated successfully, but these errors were encountered: