Should vistypes be able to implement custom query logic?

[spalger]

While attempting to implement a sample visualization for elastic/elasticsearch#16817 I found the desire to implement a query within the vistype. This would allow simply adding a custom visualization to the system and getting both support for the new correlation metric and a visualization that best represented it's output. Unfortunately doing so has proven difficult.

The approach I ended up taking was:

1. create a filter context service that gives my vistype access to the current global filters (time and filterbar)
2. expose the savedVis directly to the editor so that a custom controller could copy the filters and index pattern from the savedVis.searchSource to the vis.params.
3. add the $scope.addGenericFetcher() function, which registers a simple function with the courier that will be called everytime the courier wants to fetch "searches" (the pr is still pending).
4. read the filterContext, vis.params.index and vis.params.filters to create a query that I could then send to elasticsearch with the elasticsearch client. Unfortunately this meant writing more elasticsearch queries directly in the front-end rather than a parameterized rest endpoint, but what is a girl to do?

Hopefully we can come up with a better way to accomplish this... or decide that we don't want vistypes to try and mix the current context with their custom querying... Thoughts?

[trevan]

Couldn't this be a custom agg_type or am I missing something?

[spalger]

Well, I the issue linked above should be a custom agg type, yes. But my issue is that other visualizations (like timelion sheets for instance) need to define how they fetch their data. This is all done outside of the standard elasticsearch aggregation/search abstraction.

[timroes]

Closign this as not really up-to-date with our current infrastructure anymore :-)