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 more missing AggregationBuilder getters #25198

Merged
merged 2 commits into from
Jun 14, 2017

Conversation

polyfractal
Copy link
Contributor

Some more minor tweaks to make agg builders more consistent.

  • getMetadata for all aggs
  • various getters on TermsAggBuilder (without "get" prefix to maintain convention)
  • Also makes InternalSum's ctor public, to follow suit of other metrics (min/max/avg/etc)

@cbuescher would you mind taking a look at this? Want to make sure I'm not breaking anything related to the java client project. :)

- getMetadata for all aggs
- various getters on TermsAggBuilder (without "get" prefix to maintain convention)
- Also makes InternalSum's ctor public, to follow suit of other metrics (min/max/avg/etc)
Copy link
Member

@cbuescher cbuescher left a comment

Choose a reason for hiding this comment

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

@polyfractal thanks, I left a question around the need to access the metaData field from outside, the rest looks good.

@@ -116,6 +116,11 @@ public AB setMetaData(Map<String, Object> metaData) {
}

@Override
public Map<String, Object> getMetaData() {
Copy link
Member

Choose a reason for hiding this comment

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

Why does the metaData need to be accessible for anything other than subclasses? My current understanding is that it is used to associate state in the request with the aggregation response, so I'm not sure if we need to expose these properties.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

If the user is attempting to add metadata to a request, and doesn't have all the metadata in one place in their application, it wouldn't be uncommon to do something like:

Map<String, Object> newMetadata = new HashMap<>();
newMetadata.putAll(aggBuilder.getMetadata());
newMetadata.put("foo", "bar");
aggBuilder.setMetadata(newMetadata);

E.g. without a way to get metadata, the metadata has to be compiled into a single location in the user's application so it can be set all at once, which makes building agg trees cumbersome.
newMetadata.

Also, being able to get the metadata would is useful where aggs are built programmatically and you want to verify the final agg builder in a test.

Copy link
Member

@cbuescher cbuescher Jun 14, 2017

Choose a reason for hiding this comment

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

I was trying to understand if there is a specific reason already to do this. My understanding of "metaData" in aggegation is that it is something that is piggy backed from the request to the response and currently is mostly used by our own clients, so it shouldn't change once it has been set once. Since this it the aggregation builder it might be okay to allow this at this point. Maybe @colings86 has an opinion on this?

Copy link
Member

Choose a reason for hiding this comment

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

Talked f2f, makes sense to get a way to read the metaData here.

@@ -116,6 +116,11 @@ public AB setMetaData(Map<String, Object> metaData) {
}

@Override
public Map<String, Object> getMetaData() {
return metaData;
Copy link
Member

Choose a reason for hiding this comment

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

If we need to expose this, maybe return an unmodifyable map here.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sure, I can add that. Do we have a policy that we don't want to allow side-effects on builders, and force a get/set cycle rather than modifying in-place?

Copy link
Member

Choose a reason for hiding this comment

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

There's no definite policy, but in the Query builders we often try to limit accress to internal maps etc... once they are set. The reason there is that those objects are not only client facing "builders" any more but also our internal representation of things. This might be different in the aggregation builder case, I think its still safer to allow only read access to the metaData once it has been set.

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 okay if we can make this an unmodifiable map.

Copy link
Member

@cbuescher cbuescher left a comment

Choose a reason for hiding this comment

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

LGTM if we can make the getMetaData return an unmodifiable map.

@polyfractal
Copy link
Contributor Author

Thanks @cbuescher! :)

@polyfractal polyfractal merged commit 52719b2 into elastic:master Jun 14, 2017
@polyfractal polyfractal added v6.0.0 and removed review labels Jun 14, 2017
jasontedor added a commit to jasontedor/elasticsearch that referenced this pull request Jun 15, 2017
* master:
  Upgrade icu4j for the ICU analysis plugin to 59.1 (elastic#25243)
  move assertBusy to use CheckException (elastic#25246)
  Use SPI in High Level Rest Client to load XContent parsers (elastic#25098)
  [TEST] test that low level REST client leaves path untouched (elastic#25193)
  Speed up PK lookups at index time. (elastic#19856)
  [Docs] Fix documentation for percentiles bucket aggregation (elastic#25229)
  Upgrade to lucene-7.0.0-snapshot-92b1783. (elastic#25222)
  Build: Add master flag for disabling bwc tests (elastic#25230)
  Scripting: Rename SearchScript.needsScores to needs_score (elastic#25235)
  Support script context stateful factory in Painless. (elastic#25233)
  FastVectorHighlighter should not cache the field query globally (elastic#25197)
  Remove QUERY_AND_FETCH BWC for pre-5.3.0 nodes (elastic#25223)
  Add more missing AggregationBuilder getters (elastic#25198)
  Extract the snapshot/restore full cluster restart tests from the translog full cluster restart tests (elastic#25204)
jasontedor added a commit to glefloch/elasticsearch that referenced this pull request Jun 15, 2017
* master: (44 commits)
  Upgrade icu4j for the ICU analysis plugin to 59.1 (elastic#25243)
  move assertBusy to use CheckException (elastic#25246)
  Use SPI in High Level Rest Client to load XContent parsers (elastic#25098)
  [TEST] test that low level REST client leaves path untouched (elastic#25193)
  Speed up PK lookups at index time. (elastic#19856)
  [Docs] Fix documentation for percentiles bucket aggregation (elastic#25229)
  Upgrade to lucene-7.0.0-snapshot-92b1783. (elastic#25222)
  Build: Add master flag for disabling bwc tests (elastic#25230)
  Scripting: Rename SearchScript.needsScores to needs_score (elastic#25235)
  Support script context stateful factory in Painless. (elastic#25233)
  FastVectorHighlighter should not cache the field query globally (elastic#25197)
  Remove QUERY_AND_FETCH BWC for pre-5.3.0 nodes (elastic#25223)
  Add more missing AggregationBuilder getters (elastic#25198)
  Extract the snapshot/restore full cluster restart tests from the translog full cluster restart tests (elastic#25204)
  Refactor TransportShardBulkAction.executeUpdateRequest and add tests
  Make sure range queries are correctly profiled. (elastic#25108)
  Test: allow setting socket timeout for rest client (elastic#25221)
  Migration docs for elastic#25080 (elastic#25218)
  Remove `discovery.type` BWC layer from the EC2/Azure/GCE plugins elastic#25080
  When stopping via systemd only kill the JVM, not its control group (elastic#25195)
  ...
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants