-
Notifications
You must be signed in to change notification settings - Fork 368
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
Top level filters #17
Conversation
Would you continue to fix this? |
Of course! Can you provide me a configuration for ES that you are using to run rspecs on local machine? Thanks! |
Just |
Done. Specs run clearly on local machine. |
@@ -136,3 +138,142 @@ def _request_types | |||
end | |||
end | |||
end | |||
|
|||
# module Chewy | |||
# class Query |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is it? Could you remove it please?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, forget to do some cleanup.
As I told previously, I'm against this changes just because It uses stupid API rules. But, I've got a solution. If you will do it as an option, like |
What do you mean in stupid API rules? Filter and queries are completely not the same and producing filtered query instead of separate query and filter is completely wrong. If ES API has separate query and filter options, then we should use them. Also, I gave you and example with facets , they are completely not usable in Chewy now, because when I apply facets value as a filter, I cannot run facets again. |
@@ -85,8 +85,10 @@ def merge other | |||
end | |||
|
|||
def request_body | |||
body = (_composed_query(_request_query, _request_filter) || {}).tap do |body| |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You have removed _composed_query
usage, why didn't remove the definition?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because it is used in HasRelation queries.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So why did you remove specs for it?
And according to has_child/parent filters - is there any way to use filter and query together without composing them? Here in docs http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/query-dsl-has-parent-filter.html said: 'The has_parent filter also accepts a filter instead of a query' Is it true, have you tried?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Putted back specs for _composed_query. I removed them when tried to get off from this method, but then understood that it is used in HasRelation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will look deeply at has_child
and has_parent
and try to find any possibilities for optimisations.
I'm just asking you to make a kind of compatibility mode, Let root filter be the default, but make an option please. |
Give me an hour, I will add configuration option. |
Done. Added |
@@ -56,4 +56,4 @@ def _filters_join filters, logic | |||
end | |||
end | |||
end | |||
end | |||
end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why are you doing this? :)
Awesome, just add some specs and I'll merge this |
Done. Added basic specs for option. |
@@ -156,6 +156,20 @@ def request_body &block | |||
specify { request_body { | |||
update_options(from: 10); update_sort(:field); update_fields(:field); update_queries(:query) | |||
}.should == {body: {query: :query, from: 10, sort: [:field], _source: ['field']}} } | |||
|
|||
context do | |||
before { Chewy.filtered_queries = false } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Random specs will fail sometime, use Chewy.stub(:filtered_queries, false)
Done. Also updated |
Awesome work, thanks! |
No problem, waiting for new gem version. |
Little bit later, use github version for a while |
Hey! I've decided to dig this problem deeper: elastic/elasticsearch#6367 (comment) Waiting for https://groups.google.com/forum/#!topic/elasticsearch/Y9mLM4r7a3I answers |
Since Chewy is for ES >= 1.0 - I'll revert your PR and will implement post-filter as additional query chain method |
I will do this tonight, no problem. |
I didn't know about |
Basically we should rename |
Nope, you need to revert your changes and just add additional |
In this case there will no be incompatible changes in next release. Thanks Buddha I didn't releas this yet ;) |
Ok, then better revert my changes and I will do new PR tonight. |
You can do it in new PR, I still have no answers for other questions, so release will be after next weekend I suppose |
Ok, no problem. My vacation starts on Tuesday, so better for me to do this changes ASAP. |
Hey, just noticing you, I've reverted your code partially (filtered queries are now the only option). The only thing left - is to add |
Ok, where is code with reverted PR? |
In master already, it was reverted partially and manually :) |
Ok, I will do the rest. |
I regret, but it seems to me that I will not have enough time to do this tonight (having some production issues). Maybe tomorrow. |
It's done already, check it out in master please. Anyway, thanks for pointing me on this problem. |
No description provided.