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

Add Autosense annotation for query dsl testing #18211

Merged
merged 10 commits into from
May 17, 2016

Conversation

MaineC
Copy link

@MaineC MaineC commented May 9, 2016

This adds the autosense annotation to a couple of query dsl docs files and fixes the snippets to work in the tests along the way.

Still needed: Switch from autosense to console, convert remaining query dsl docs.

Relates to #18160 / @nik9000

@MaineC MaineC self-assigned this May 9, 2016
@MaineC MaineC added >docs General docs changes >test Issues or PRs that are addressing/adding tests WIP v5.0.0-alpha3 labels May 9, 2016
{
"query": {
Copy link
Member

Choose a reason for hiding this comment

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

I'm not sure if it is ok to confuse indention? I like two spaces and some of the snippets use that but this uses both two and four spaces now.

Copy link
Author

Choose a reason for hiding this comment

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

Good point - this really was more me being too lazy to reformat than anything else, but I agree it makes a lot of sense to keep these the same within one file.

Isabel Drost-Fromm added 4 commits May 10, 2016 11:54
this adds the autosense annotation to a couple of query dsl
docs files and fixes the snippets to work in the tests along
the way.
... and range, and terms...
@MaineC MaineC force-pushed the docs/add_autosense_to_query_dsl branch from 6a0522a to ab4367c Compare May 10, 2016 11:00
@@ -81,7 +81,7 @@ all documents where the `status` field contains the term `active`.
This first query assigns a score of `0` to all documents, as no scoring
query has been specified:

[source,json]
[source,js]
Copy link
Member

Choose a reason for hiding this comment

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

Do you think we ought to complain for anything [source,json]? It'd be super easy to print a warning/fail the build.

Copy link
Member

Choose a reason for hiding this comment

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

I'd like us to be consistent here but I hesitate to pull the trigger on that.

Copy link
Author

Choose a reason for hiding this comment

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

No idea really, though in general I'm in favor of consistency - makes it easier for new comers to adopt existing style.

Choose a reason for hiding this comment

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

In fact the syntax highlighter recognise js, not json, so yes would be good

Copy link
Member

Choose a reason for hiding this comment

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

I'll make a PR!

@nik9000
Copy link
Member

nik9000 commented May 10, 2016

LGTM

@MaineC
Copy link
Author

MaineC commented May 12, 2016

Modified the remaining query-dsl docs.

Before going ahead and merging I'd appreciate some feedback in particular to the changes made to docs/reference/query-dsl/geo-polygon-query.asciidoc and docs/reference/query-dsl/parent-id-query.asciidoc - examples in both needed a bit of adjustment to get past parsing at all. A second pair of eyes stating that the result is equal to the intent of the example before would be welcome.

"points" : [
"query": {
"bool" : {
"must" : {
Copy link
Member

Choose a reason for hiding this comment

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

Does it work if you leave that out?

Copy link
Member

Choose a reason for hiding this comment

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

Actually I wonder if it'd be better not to use it in the filter context? Like, can you just remove the bool entirely? If it needs the bool we should probably explain why it does. But that can be in another PR I think.

Copy link
Author

Choose a reason for hiding this comment

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

I had the same thought when making those changes but decided to keep changes minimal and post-pone this to a later PR.

It does parse successfully without being surrounded by the bool query. Not sure if this is a left-over of the filter to query migration. @nknize @clintongormley

Choose a reason for hiding this comment

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

It is only cacheable if it is inside the bool.filter clause, so I would leave it there. (although perhaps delete the bool.must.match_all?

Copy link
Author

Choose a reason for hiding this comment

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

Makes sense. Will do in a separate PR and apply the same modification to any other reference/query-dsl/geo* docs that have the same structure.

@nik9000
Copy link
Member

nik9000 commented May 12, 2016

I left a comment on the geo-polygon query but overall it looks pretty similar? I think the parent query changes are good.

MaineC pushed a commit to MaineC/elasticsearch that referenced this pull request May 24, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
>docs General docs changes >test Issues or PRs that are addressing/adding tests v5.0.0-alpha3 WIP
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants