[/] yet another search quirk

Searching on "Bachman Turner" returns no results. It appears to be stymied by the hyphen in "Bachman-Turner Overdrive."

I had a similar thing with the apostrophe. "Larks Tongues" had no result, I had to type in "Larks' Tongues".

Diacritical marks pose a similar problem: "Sinead" doesn't find Sinéad O'Connor.

It's clear that the rudimentary search I have in place is just not cutting it. Simple searches like "Sinead" should be producing meaningful results. Especially when she passes away, that's the time when she should be appearing in results.

I'm going to look into pro level search services. A few years ago the affordable options were fairly limited but I think there might be some decent options, even on free tiers, that could work for us.


Kevin

I don't recall this being an issue on the old site -- is it not possible to reuse that search setup?

FWIW, searching on the full name of a band/artist/album without the necessary punctuation/diacritics (Bachman Turner Overdrive, Sinead O'Connor, Larks Tongue in Aspic) will return the desired result, at least in a list among others. It's just a problem searching on substrings of those names.

I've done a preliminary test with a 3rd party search service and it does a really nice job with all these edge cases and would be much easier to maintain on that front. I'm going to try and go that route as soon as I can.

Right now I'm facing a code base issue where some legacy external packages are causing a major headache on the backend. I'm going to have to do a deep dive to get the system up and running to the latest specs available.


Kevin

I've gone deep on installing a 3rd party search engine for the site. It's a service named Algolia and is compatible with the underlying system software / database.

All the search issues that have been listed here are resolved with this most sophisticated search engine:

Sinead
Bachman
Larks Tongue

Please try it out and see if everything is being sourced as you'd imagine.

Note: after a set number of searches per month I start getting billed for additional requests. It's not that much money so I'm not sweating it, however I've taken Label searches out of the default search requests as each search is already 4 distinct searches across data indexes: bands, albums, artists, aliases. I'll try moving label searches to an admin page.


Kevin

Nice! Search results aren't missing anything obvious now, but I wonder if it's possible to tinker with the ordering of the results. For instance, if I search on "Miles Davis" I get a bunch of groups he led, with his solo act showing up 6th, followed by band aliases, albums, and finally artists -- but Miles himself appears after David Mies. (Likewise, Eric Clapton appears after Ric Clayton, George Harrison appears after George Harris, etc.)

I also noticed that searching for band names like "The Kinks" or "The Byrds", where "The" isn't in the primary name according to our peculiar rules, means the name gets buried in the alias listing after a bunch of unrelated bands.

I can put in some sorting tweaks for specific edge cases. Thankfully sorting is much easier than the actual search part so if the desired result (Miles Davis for example) is in the set of results returned by Algolia, I can do some specific sorting actions to help make the results more intuitive.

Let me see what I can set up here...


Kevin

One possible tweak: If there are listings that have the exact (sub)string being searched for, then there's no need to expand to fuzzy matches. That would avoid the Miles Davis/David Mies type problem.

So I've added a couple of sorting additions once I receive back the search results from Algolia.

1) Miles Davis rule
- If a Band or Artist is an exact match for the search string and isn't at the top of the results list for that model type, simply move it to the top.
- Miles Davis now appears at the top of the list of bands.

2) The Kinks rule
- If a Band Alias (or Artist alias) exactly matches the search query, and there isn't an exact match in the non-aliased models (Bands or Artists), display Band Aliases before Bands. This way the exact match result will appear further up the page than non-exact matching results
- The Kinks are at the top of Band Aliases and Band Aliases now appear before Bands
- A search on 'Madonna' returns Bands first with an exact match, Albums, Artist Aliases win an exact match, then Artists

On these edge cases I want to try and target these issues as directly as possible to avoid unforeseen consequences down the line.

As for fuzzy matches, I don't control how Algolia performs their searches. If there is an exact match, it will still continue to look for alternatives, and I simply cap the maximum number of objects returned. I don't think there is a setting to 'stop if exact match is found' unfortunately.

Let me know if there are any more search concerns otherwise I'll move on to the next set of issues to resolve...


Kevin

All looks good now!

Might want to add another sorting rule to account for parentheticals. If I search for "Eric Peterson" the exact matches of Eric Peterson (US 1), (US 2), and (US 3) are buried under various fuzzy matches.

I'm getting the sense that if something exists solely on the wiki side, it won't show up in search results at all. Example: pin_punk has recently entered a couple of Godcollider albums, but "Godcollider" doesn't return anything.

I’ve noticed that as well, but only for really recent entries, the ones I did on the same day. Perhaps they don't immediately 'sink in' anymore?

Ah, right you are, those Godcollider queued releases show up in search now.