Query Max Length

Using the Laravel Scout API implementation, I am receiving an error:

Invalid value for “query” parameter, expected string with a length < 512

Is there any way to exceed the 512 character limit for search strings? I do not see anything in the docs regarding this limitation.

Hi Derek,

Can you give us more details about your use case? I’d like to understand how you use the engine to I can help you better.

Thanks!

I am using the Laravel search method to search through a library of content. We are using the same search box to search through Article titles and tags. The search term includes a comma-delimited list of tags associated with a user, so the term can become long (~800-1000 characters).

$searchResultIds = Articles::search($term)
    ->get()
    ->pluck('id');

$this->articles->whereIn('id', $searchResultIds);

So if I understand write, you are searching is post titles and tags and your query is something like:

alpha, beta, gamma, tag1, anothertag

I think this isn’t the right approach. Can you describe the original problem, why do you have have a list of tags associated with user? I’m not sure you’ll get the most relevant results with such a long query. This might be a good use case for facets instead.

Please explain, I’ll be happy to help.

@julienbourdeau we also have a similar use case. We are a property classified and we want agents to filter their listings by searching in bulk through their property reference ID. Their behavior is to search hundreds of listings at once. Based on this use case, ideally we would need to have a much higher limit. What do you suggest?

Hi,

I’m not sure to understand what makes the query string so long. Do you mean that you put all the reference ID in the query?

?query=xxxxx,yyyyy,zzzzz

In this case, I wouldn’t use search but getObjects to retrieve the records you need by referenceID (reference ID need to be use as objectID then)

Feel free to share more information abour your use case and your search experience, so I can help better.

HI @julienbourdeau. Thanks for responding.

Yes, that’s precisely the use case. However, our objectIDs are already something else (the actual DB ID field for the records). We’d want to keep it that way. However, is it possible to create a separate secondary algolia index with the Ref IDs (and algolia manages that index, like it manages secondary indices for different sort orders)?

Is there any other way we can achieve this search?

Maintaining a second index with this reference as the objectID is probably best.

I’m not sure to understand how your search works to be honest but one other solution could be to to query your backend (but I understand that you want to use InstantSearch and such) . This is not really a search, more a typical SQL query WHERE id IN (...).