Skip to content
This repository has been archived by the owner on Nov 22, 2017. It is now read-only.

Multi-valued arguments #121

Open
rashidkpc opened this issue May 16, 2016 · 6 comments
Open

Multi-valued arguments #121

rashidkpc opened this issue May 16, 2016 · 6 comments

Comments

@rashidkpc
Copy link
Contributor

Currently support for multi-valued arguments to functions are handled independently by the receiving function. This requires users to pass a specially formatted string, for which there is currently a basic convention:

.es(metric="cardinality:user")

This works well enough for simple key-value situations. But it falls apart for more complex cases. For example, the cardinalitymetric above can take a precision_threshold parameter. How do we handle that?

It would be easy to add a 3rd parameter, eg cardinality:user:200, but this won't be shared metric aggs, and all of the arguments will be positional. Gross.

I could add an alternate form allows for an opts function that generates an object to be passed into complex arguments

.es(metric=.opts(type=cardinality, field=user, precision_threshold=200))

Pros

  • Super flexible
  • Does not introduce new language constructs
  • Can use existing parser, would only require the ability to define arguments that don't have positionally.
  • Could use it for multi-value aggs. Eg .es(metric=.opts(type=percentiles, field=bytes per=1, per=10, per=50, per=90))

Cons

  • .opts() is essentially a datasource, but it only does anything if passed as an argument somewhere that makes sense, and there's nothing you'd chain to it to.
  • .opts() would need to be excluded from autocomplete. This is the easy way to handle it. In reality, better context support in the autocompletion would be ideal.
  • Auto completion for .opts() will be really hard

I think the key here is that this would really need to be optional, as it creates some really long arguments

This was referenced May 16, 2016
@yuvalzaltz
Copy link

I like the opts option which provides max flex.
Autocompletion is a problem but if it would be documented in docs i guess it would be good enough.

@rashidkpc
Copy link
Contributor Author

The more I think about this the more I think an improved expression editor is a pre-req

@eprothro
Copy link

+1 for this problem being solved. As a beginner I did:

As a beginner I tried .es(metric=percentiles:service) and saw an empty chart. Realizing I needed to provide options, I expected something like:

.es(metric=.metric(service, percentiles, percents=[68,95,99]))

@v01t
Copy link

v01t commented Nov 28, 2016

+1
Missing percentiles metric, expect to have it before... by this missing functionality all latency calculations become very limited (max,min,avg)

Please add it.

Thanks for your great job.

@daveres
Copy link

daveres commented Mar 14, 2017

+1

@tommikiviniemi-srs
Copy link

This would be hugely appreciated by us. +1.

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

No branches or pull requests

6 participants