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

Make Singnals usable in queries. #17211

Open
nyurik opened this issue Mar 16, 2018 · 6 comments
Open

Make Singnals usable in queries. #17211

nyurik opened this issue Mar 16, 2018 · 6 comments
Labels
enhancement New value added to drive a business result Feature:Vega Vega visualizations Team:Visualizations Visualization editors, elastic-charts and infrastructure

Comments

@nyurik
Copy link
Contributor

nyurik commented Mar 16, 2018

From @thatguy7 on February 26, 2018 17:7

Hi,
My goal is to have two queries, over two separate indices, where the second one depends on the results of the first one.

I can extract the necessary values from the first query and store them in a signal, but I cannot actually use any signals inside the 'url' object.

Is there a chance this feature will be added, or is present but I am using it wrong?

Copied from original issue: nyurik/kibana-vega-vis#46

@nyurik nyurik added enhancement New value added to drive a business result upstream labels Mar 16, 2018
@nyurik
Copy link
Contributor Author

nyurik commented Mar 16, 2018

Hi @thatguy7, this is not yet possible -- it has been requested before, and there is some work being done on it at vega/vega#912

@nyurik
Copy link
Contributor Author

nyurik commented Mar 16, 2018

P.S. On the second thought, it is possible to do a workaround inside Kibana, but I would really like to wait for the dynamic data support first, or else it will be a relatively hacky solution. As a syntax, we could have something like this inside the the data url block. Would that work for you?

data: { url: {
    "aggs" : {
        "xxx" : {
            "terms" : {
                "field" : { "%signal%": "mysignal" }
            }
        }
    }
}}

@nyurik
Copy link
Contributor Author

nyurik commented Mar 16, 2018

From @thatguy7 on February 27, 2018 8:12

That could work for me and be used as an interim solution, until the dynamic data support is figured out. My current approach was creating a data object, then a scale from it, then a signal containing the domain of that scale as a list of terms that I want to filter by. Then that signal should have determined the query of a second data object.

I am not sure if adding that syntax would make this possible, since the signal's value would be decided by the first query, and affect the other then - so I would need to be sure the signal has the right value at the time the second query is performed.

I would greatly appreciate it, if this functionality was added. I am currently figuring out the most suiting way to store our data in Elasticsearch for further evaluation. Right now I am resorting to nesting some data, but that structure does not play well at all with Kibana and is not very flexible - but still usable with the Vega plugin.

So ideally I would just split it into multiple indices and do two queries, where I can first determine some terms in one query which depends on the Kibana context and then use those terms as filters in the second query. This would mean I can still preserve the relationship in the data, while being able to work with it in Kibana separately.

@nyurik
Copy link
Contributor Author

nyurik commented Mar 16, 2018

@thatguy7 would the signal be based on a user action, or would it be calculated from the original data?

@nyurik
Copy link
Contributor Author

nyurik commented Mar 16, 2018

From @thatguy7 on February 27, 2018 17:14

It would be calculated from the original data.

As I tried to outline it in my previous post, I want to perform a terms aggregation with the context of Kibana applied on index1 - I do this to get the all the IDs of the documents in index1 that match the context.
From this aggregation I define a scale, so I get a nice array as its domain, that contains all these IDs. These are then stored in the signal, which I want to use to perform the second query on index2, where every document has a field that matches it to the ID of the first index.

This way I do two queries, where first I get a list of document IDs from index1 that match certain filters and fall in a certain time range, and then a second one that aggregates statistics of the data in index2, but only for documents that are related to the documents that were matched in index1.

In a nutshell, I want to filter data in index2 by fields that are in index1.

@nyurik nyurik added the Feature:Vega Vega visualizations label Mar 16, 2018
@timroes timroes added the Feature:Visualizations Generic visualization features (in case no more specific feature label is available) label Aug 8, 2018
@timroes timroes added Team:Visualizations Visualization editors, elastic-charts and infrastructure and removed Team:Visualizations Visualization editors, elastic-charts and infrastructure Feature:Visualizations Generic visualization features (in case no more specific feature label is available) labels Sep 16, 2018
@jonatelo
Copy link

jonatelo commented Mar 10, 2020

Any advance on this issue? In a similar way, I'm trying to change the index name using a signal input.

"signals": [
    {
      "name": "level", 
      "value": "host_correlations", 
      "bind": {
        "input": "radio", 
        "options": ["host_correlations", "app_correlations"]
      }
    },
"data": [
    {
      "name": "tree",
      "url": {
        **"index": {"signal": "level"},**
        "body": {
          "size": 10000,
          "query": {
            "match": {
              "data": "nodes"
            }
          }
        }
      },

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New value added to drive a business result Feature:Vega Vega visualizations Team:Visualizations Visualization editors, elastic-charts and infrastructure
Projects
None yet
Development

No branches or pull requests

4 participants