Skip to content

Split HasChildQueryParser into toQuery and formXContent#13333

Merged
s1monw merged 1 commit intoelastic:feature/query-refactoringfrom
s1monw:has_child_query_parser
Sep 8, 2015
Merged

Split HasChildQueryParser into toQuery and formXContent#13333
s1monw merged 1 commit intoelastic:feature/query-refactoringfrom
s1monw:has_child_query_parser

Conversation

@s1monw
Copy link
Copy Markdown
Contributor

@s1monw s1monw commented Sep 3, 2015

This is an intial commit that splits HasChildQueryParser / Builder into
the two seperate steps. This one is particularly nasty since it transports
a pretty wild InnerHits object that needs heavy refactoring. Yet, this commit
has still some nocommits and needs more tests and maybe another cleanup but
it's a start to get the code out there.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the type and queryBuilder instance members could be made final

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd love to make all the things here final and remove that builder stuff but maybe we do this later?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes lets do it later otherwise we have to remove setters and break things.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

but that's the point of this refactoring right? I am not saying we should now but we have to

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sure things changes now that we know for sure the target branch, that said making everything final would be better to do once we merged back to master to prevent merge conflicts here. Same with renaming XYZQueryBuilder to XYZQuery, and moving to proper getters and setters.

@javanna
Copy link
Copy Markdown
Contributor

javanna commented Sep 4, 2015

I didi a first review round, especially on the query refactoring aspects, and left some comments. I'll have to dive a bit deeper into the inner_hits changes to better understand it.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought the default was 0 in the previous parser, wasn't it? did you make this change on purpose?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah which was then turned into MaxINt on the server

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can go back to the previous

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see! I think your change makes it clearer actually, looks good

@s1monw s1monw force-pushed the has_child_query_parser branch from 887ca3c to ed3a719 Compare September 6, 2015 20:16
@s1monw
Copy link
Copy Markdown
Contributor Author

s1monw commented Sep 6, 2015

@javanna I think it's ready can you give it another go

@s1monw
Copy link
Copy Markdown
Contributor Author

s1monw commented Sep 7, 2015

@cbuescher since luca is out can you take a look?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In some previous discussion for other builders we tried to set default values for non primitive types that have a default, setting to null effectively means use the default, same as specifying field: null in the json query. Maybe we can keep this here (and in the following setters that have default values)

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if you want to set this to default you shouldn't pass null to this. Passing null makes no sense here at all you can just pass None and passing null is 100% of the time a bug

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, we might have to revisit some other queries we refactored then.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we can simplify here and print everything out, default values included, that's what we went for in all of the other queries too.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

++

@cbuescher
Copy link
Copy Markdown
Member

Added one more minor comment, LGTM otherwise.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I do like this change, it simplifies things a lot. What I am wondering though is if it was simply wrapping a search source, or also hiding that inner_hits don't support everything that can be put within a search source. For instance, the query element doesn't seem to be supported, as well as other parse elements I'm afraid. This becomes a problem in the java api only I think, cause you can potentially set things that aren't supported. Maybe it is ok for now....

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah I think we should just let it be like this for now and fix it along the way. I had it as a TODO on some calsses but maybe it's too much for now?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

:Search/Search Search-related issues that do not fall into other categories

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants