fix(fulltext-search): don't allow search queries of less than 3 characters (DEV-1602)

[mdelez]

resolves DEV-1602

[musicEnfanthen]

Sorry for jumping into this PR, but may I ask from a project perspective why this limit of 3 characters is needed? (Sorry, I do not have access to the JIRA description of the issue.)

I always thought this was a limitation of the old search engine in SALSAH? In our project, we are sometimes encountering 2-character name parts, like "Fu Du" or "Li Bai", or even catalogue work numbers like "M1" to "M9" which cannot be found with this restriction. But maybe there are still some technical reasons for the limit?

[Vijeinath]

Sorry for jumping into this PR, but may I ask from a project perspective why this limit of 3 characters is needed? (Sorry, I do not have access to the JIRA description of the issue.)

I always thought this was a limitation of the old search engine in SALSAH? In our project, we are sometimes encountering 2-character name parts, like "Fu Du" or "Li Bai", or even catalogue work numbers like "M1" to "M9" which cannot be found with this restriction. But maybe there are still some technical reasons for the limit?

@mdelez Maybe I wait with my review until we discussed this. This point seems valid.

[mdelez]

@musicEnfanthen The API still has a requirement of at least three characters for a full text search for performance reasons. This PR makes the app handle the situation of a user searching for less than 3 characters more gracefully. If you have resources with 2 character labels, you can add an * at the end as a workaround. As long as there aren't too many resources starting with the provided 2 characters, it shouldn't be a problem.

[Vijeinath]

Works for me

[musicEnfanthen]

Ok, I see. Many thanks, @mdelez, for the explanation, and the workaround.

If you have resources with 2 character labels, you can add an * at the end as a workaround

Maybe it could be worth to add some tests for this edge cases, that is, that "aa*" really finds "aa", "aab" and "aalongword"?

[mdelez]

Maybe it could be worth to add some tests for this edge cases, that is, that "aa*" really finds "aa", "aab" and "aalongword"?

This isn't something that unit tests can cover because the API calls in these tests are mocked. In other word they are fake replies because testing real API calls is more the job of e2e tests which we are currently migrating due to the e2e library we were using being deprecated.

[musicEnfanthen]

Thanks for your patience and explanations. Totally makes sense, and gives a better understanding. Many thanks!