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

Revisit _shard / class names in exposing terms stats for scripts #4584

Closed
kimchy opened this issue Jan 2, 2014 · 1 comment
Closed

Revisit _shard / class names in exposing terms stats for scripts #4584

kimchy opened this issue Jan 2, 2014 · 1 comment

Comments

@kimchy
Copy link
Member

kimchy commented Jan 2, 2014

The recent feature, #4161, include support for exposing lucene data / statistics for scripts. The naming though is misleading potentially, both on the class names and on how to access it in scripts.

The _shard key is used to access it in script. The class names are ShardTermsLookup, ScriptTerms, ScriptTerm for example. The _shard name feels too generic, while the terms names in the class names is misleading, since one can get data not only for terms (like doc count).

I think we can try to find a good name for it, and derive the script name and class names from it. Some thoughts include:

  • _ts (script) / TermsXXX (class): though not all data exposed relates to terms, it encapsulates most of the stats one can get. The down side is, of course, that one can get more info than just terms.
  • _stats (script) / StatsXXX (class): most of the data that is exposed relates to statistics information. Though again, not all, for example, payload... .
  • _index (script) / IndexXXX (class): this is an "inverted index" level information, stats and other information that can be derived from the index itself.

I am personally leaning towards _index.

@s1monw
Copy link
Contributor

s1monw commented Jan 2, 2014

+1 for _index I wanted to suggest the same thing

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

Successfully merging a pull request may close this issue.

3 participants