Skip to content

Vs refactor javadoc and comment cleanup #53427

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

Conversation

not-napoleon
Copy link
Member

@not-napoleon not-napoleon commented Mar 11, 2020

This PR adds Javadoc for the aggregations.support package, as well as for several key classes in the refactor. Additionally, I cleaned up some TODO comments that either got fixed or no longer apply, renamed a few variables, oh, and deprecated ValueType.

Relates to #42949

@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-analytics-geo (:Analytics/Aggregations)

@not-napoleon not-napoleon requested a review from nik9000 March 11, 2020 18:44
…doc-and-comment-cleanup

 Conflicts:
	server/src/main/java/org/elasticsearch/search/aggregations/support/CoreValuesSourceType.java
@@ -18,5 +18,25 @@
*/
package org.elasticsearch.search.aggregations.support;

/**
* {@link AggregatorSupplier} is a place holder interface. The {@link ValuesSourceRegistry} uses this as a common interface for tools to
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 really sure what you mean by place holder. Like, you mean that we'll replace it with another one later? Does this interface just exist to mark things that the registry can handle?

* subclass of {@link ValuesSource} should have a corresponding implementation of this interface. In general, new data types seeking
* aggregation support should create a top level {@link ValuesSource}, then implement this to return wrappers for the specific sources of
* values.
* {@link ValuesSourceType}s are the quantum unit of aggregations support. {@link org.elasticsearch.index.mapper.MappedFieldType}s that
Copy link
Member

Choose a reason for hiding this comment

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

Maybe something like `{@link ValuesSourceType}s represent data types on which aggregations can operate. On data nodes they are {@link resolved} to {@link ValueSource} instances that blah blah blah"

I'm not sure it is useful to explain too much about subclasses of ValuesSource here. I think I'd prefer to read that on ValuesSource.

* will yield the same ValuesSource subclass. This typically happens when the underlying representation is shared, but logically the data
* are different, such as with numbers and dates.
*
* ValuesSourceTypes should be stateless, and thus immutable. We recommend that plugins define an enum for their ValuesSourceTypes, even
Copy link
Member

Choose a reason for hiding this comment

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

👍 on calling out stateless. Though I don't think you need to call out that that implies they are immutable.

*/

/**
* The Aggregations Support package holds shared code for the aggregations framework, especially around dealing with values.
Copy link
Member

Choose a reason for hiding this comment

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

s/The Aggregations Support package// ? The topic of the sentence is sort of implied by its position as package javadoc.

/**
* The Aggregations Support package holds shared code for the aggregations framework, especially around dealing with values.
*
* Key Classes
Copy link
Member

Choose a reason for hiding this comment

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

You probably should add html to this, just so it renders in a sane way when I mouseover the package and the like.

*
* Key Classes
*
* {@link org.elasticsearch.search.aggregations.support.ValuesSource} and its subclasses
Copy link
Member

Choose a reason for hiding this comment

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

Since this is in the package do you need to fully qualify it? In general I'm fine importing things only for Javadoc if it makes the javadoc easier to read.

Copy link
Member Author

Choose a reason for hiding this comment

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

AFAICT, package-info.java always requires fully qualified names in links, no idea why.

* dependent on a user specified parameter (precision in that case).
*
* {@link org.elasticsearch.search.aggregations.support.ValuesSourceRegistry}
* ValuesSourceRegistry stores the mappings for what types are supported by what aggregations. It is configured once during startup, when
Copy link
Member

Choose a reason for hiding this comment

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

s/once during startup/at startup/ ?

Copy link
Member

@nik9000 nik9000 left a comment

Choose a reason for hiding this comment

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

LGTM

…doc-and-comment-cleanup

 Conflicts:
	server/src/main/java/org/elasticsearch/search/aggregations/support/CoreValuesSourceType.java
@not-napoleon not-napoleon merged commit 573c307 into elastic:feature/extensible-values-source Mar 19, 2020
@not-napoleon not-napoleon deleted the vs-refactor-javadoc-and-comment-cleanup branch March 19, 2020 14:01
@not-napoleon not-napoleon restored the vs-refactor-javadoc-and-comment-cleanup branch March 25, 2020 18:35
not-napoleon added a commit to not-napoleon/elasticsearch that referenced this pull request Mar 26, 2020
not-napoleon added a commit that referenced this pull request Mar 31, 2020
* ValuesSource refactor wire up missing agg (#53511)

Part of refactoring ValuesSource in #42949

* ValuesSource refactoring: Wire up ExtendedStats aggregation (#53227)

* Javadoc for ValuesSource related work (#53427)

Co-authored-by: Andy Bristol <andy.bristol@elastic.co>
Co-authored-by: Christos Soulios <1561376+csoulios@users.noreply.github.com>
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