Trailing whitespace in the query is not supported

[bojanbogdanovic]

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.

[thomascorthals]

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?

[bojanbogdanovic]

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.

[mkalkbrenner]

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()?

[thomascorthals]

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?

[mkalkbrenner]

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.

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.