Query complications


One of the complications we previously encountered was the inability to search in middle of a word, the ability to do so is crucial as, we solved that by following the suggestion at this link:

Every product now has a long array with it’s code split piece by piece, the search speed hasn’t really been affected much so this had been fine, but as the database grew, currently at 10 000 items stored, we’ve encountered another bad flaw.

Codes for said items could be as long as “2H6 131 723, 2H6 181 T3, 82316662 ,01260366 28-16” or as short as “T3”.

What ends up happening now is if anyone searches for “T3”, everything alphabetically ahead of it will be shown first, so in the case above, the code starts with a “2H6”, this put’s it (and many others) ahead of simply “T3” in the results list, simply because it contained at some point after the first letter.

This makes it so the user needs to scroll through all these results that are being shown ahead of the result someone might be searching for.

Is there any way to make the attribute “data.code” the priority when querying?
Which I believe would fix the improper way the results are returned, so if T3 was a match in the “data.code” attribute, it would return it first, then return the (in this case) “data.defaultReferences”, which is the array mentioned above that the code has been split to?

Is there any better way of doing it?

The best solution of all was if Algolia had intentions of implementing any future update which allows mid word querying.

Thanks again for the constant support

Best Regards

Hi @Zango, could you write in at support@algolia.com, provide your application ID and give us support access for at least 7 days so that we can look at your configuration and maybe offer some solutions?