Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adding type prefix for query_string search #37

Closed
wants to merge 1 commit into from

Conversation

quangdutran
Copy link

Since searching is using standard analyzer which analyzes the word "client's" for instance as it is, hence searching with key word "client" will return missing results.
phrase_prefix will cover this case.

@cars10
Copy link
Owner

cars10 commented Nov 17, 2020

Hey @quangdutran , thank you very much for contributing to elasticvue.

I am currently validating this change, but i have to admit that i am not entirely happy with it. I do see your problem (i can easily replicate this), but treating queries like "client", "clients" and "client's" equally really sounds like you should alter your data at index time (using a custom analyzer and removing special characters via filters).

But i understand that nobody wants to add more analyzers to the index just so it works with elasticvue. So instead of forcing users to use the phrase_prefix analyzer (which might not work for some people), what do you think about adding an option to the search interface?
I am thinking about a selectbox (or text input) where users can enter what search analyzer they want to use. It should default to the standard analyzer and is probably hidden behind the "more options" initially.

Do you think that this could help you?

@quangdutran
Copy link
Author

Excellent idea @cars10
This will even help users to choose analyzers that they want

@cars10
Copy link
Owner

cars10 commented Jan 4, 2021

Hey @quangdutran , i am currently revisiting this feature. Upon implementing it i was playing around with additional options to add to the search form, but there are alot of possible options that users might need. So instead of adding every single one, what do you think about this aproach?

image

The idea is that the user can customize the whole query to his needs. I

@quangdutran
Copy link
Author

Yeap, this way, user can add some additional settings of the query as he wants, covering all the possible options that user might need.
However, to make sure that the syntax is right, I have to check the doc again before type in the custom part, which is kinda painful, but I guess that is ok if users want to have a special customization for searching query.

@cars10
Copy link
Owner

cars10 commented Jan 25, 2021

Hey, just wanted to let you know that i released version 0.32.0 where this is finally implemented. Let me know if you have any issues.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants