solariumphp
Trailing whitespace in the query is not supported
Solarium version(s) affected: 6.3.* Solr version: all Solr mode: standalone / cloud
Description This is a follow-up of: https://www.drupal.org/project/search_api_solr/issues/3509593
There are Solr lookup implementations where you actually want a suggestion after a space, for example with the "FreeTextLookupFactory" and using the space as separator.
Solarium trims whitespace on the query, which limits the capabilities of Solr suggesters like "FreeTextLookupFactory".
How to reproduce See: https://github.com/solariumphp/solarium/blob/6.3.7/src/Component/QueryTrait.php#L34
Possible Solution Only trim on the left side of the query or remove trim function completely from the setQuery method.
Only trim on the left side of the query or remove trim function completely from the setQuery method.
Are there any use cases where a left side space is relevant?
Not that I'm aware of. For me there is a specific case for the trailing space. I would remove the trim function, which is in my opinion cleaner and gives more flexibility.
I think at least we should keep the trim for the left side.
Maybe it is right to leave all of that to the client and to not touch the query at all. On the other hand, it might help in some cases. And it is in the lib since 15 years. Could be a breaking change.
What about introducing something like setRawQuery()?
Right-to-left scripts might run into the same issue with only ltrim() as left-to-right scripts would with only rtrim(). I'd avoid trimming from one side only.
I'm in favour of the setRawQuery() idea because I can imagine changing this behaviour will break things for users. Or maybe make it configurable with the current trimming as the default?
Right-to-left scripts might run into the same issue with only
ltrim()as left-to-right scripts would with onlyrtrim(). I'd avoid trimming from one side only.
Good point!
I'm in favour of the
setRawQuery()idea because I can imagine changing this behaviour will break things for users. Or maybe make it configurable with the current trimming as the default?
You're right. A configuration option would be better from client's perspective. Calling different methods requires code changes in any framework. Ideally the user could set the config option or implement an EventSubscriber without waiting for new release of a framework.