Select table fields in the query control for type=table queries about grafanajsondatasource HOT 14 CLOSED

Do you agree that a timeseries-query always has one metric and a timestamp?

I don't really undestand the question. When I query for a metric that returns timeseries-like data, in my case it usually returns multiple "targets". Each of them has its datapoints. Can be seen in docs in example timeseries response.

Do you agree that a table-query usually has many columns, regardless of what the backend is?

No. Sometimes 1, 2, 5 or 1000. No rule.

Do you agree that Grafana is not suited to render a table with lots of columns?

Not sure, Grafana devs can answer it.

Do you agree that from the above we can derive that some kind of UI is needed for the user to choose what columns the table should show?

As I said, I'm not against it. It's not needed though.

Why does every database datasource, MySQL, ElasticSearch,... have a query panel to control the list of columns in the table? If you want to abstract that, we need a selection box, don't we?

Probably "easier" user input. Never used it myself, I prefer to enter SQL directly.

from grafanajsondatasource.

Do you agree that a timeseries-query always has one metric and a timestamp?

I don't really undestand the question. When I query for a metric that returns timeseries-like data, in my case it usually returns multiple "targets". Each of them has its datapoints. Can be seen in docs in example timeseries response.

Same here. This is a naive assumption- look at e.g. the prometheus or influx datasources for counter examples.

Probably "easier" user input. Never used it myself, I prefer to enter SQL directly.

Same here. I feel you want to solve a particular use case that is too specific for us to address or not a pain point.

Again- if you want to contribute a PR to implement this- please feel free.

from grafanajsondatasource.

The purpose of this datasource, as I perceive it, is to abstract from underlying infrastructure. That said it gives you ability to visualise data regardless the source your backend gets it from, be it mysql, postgres, clickhouse or anothe api.
So there are no tables here.

but

We have Metrics. Currently, there's /search endpoint providing the list of Metrics. I can imagine there can be another endpoint providing variable options for specific Metric. Those options could be then configured via datasource UI.

Can you create PR with such feature?

from grafanajsondatasource.

Fully agree with your first statement except the last line. You do support table queries in addition to timeseries queries and these return columns and rows.

Yey, you can select the metrics and for timeseries that is enough as there is only time+metric. But for table queries a feature to select the columns would be needed.

The point I don't get is the "create PR". Of course, one option would be to support that in Grafana directly. Their response will be that each data source has different needs, hence it will be better to implement that within the datasource. For example the MySQL datasource allows you to select the columns by typing in the SQL query.

I am not 100% sure I got it all right but can you spot anything wrong in my current thinking?
Just to doublecheck: A datasource control can have own UI controls, can't it?

from grafanajsondatasource.

I think the point is that we don‘t see immediate need ourselves for this feature. Therefore help wanted. We‘ll consider contributions but not implement it ourselves at this time.

from grafanajsondatasource.

You do support table queries in addition to timeseries queries and these return columns and rows.

I meant concept of database tables. Sorry.

for table queries a feature to select the columns would be needed

AFAIK it's possible to hide them via Column Styles Grafana feature.

from grafanajsondatasource.

Are we still talking about different things or am I missing your point??

Your datasource does support timeseries and table type queries.

My request is, after the user has selected a table, I'd like to show a List control with the list of all table columns and let the user active/deactivate each. This list is attached to the query element so that the query response returns these columns only.

Yes, hiding columns is possible but
a) that is not a feature meant to hide 495 columns out of 500
b) it is weird to produce the data for all 500 columns just to hide 495 of them.

As I am new to Grafana, angular, datasource plugin development I was hoping to get some help. It should be quite simple for you, shouldn't it?

1. Add the List control to the partial/query.editor.html and make sure it is shown only when a table had been selected.
2. Populate the control via a rest endpoint.
3. Add the list of selected columns to the query object in order for the query-request to contain the list of columns to return.
4. Beautifications later: Adding type icons to each column in the list; dynamic filters to navigate quickly through the list of 500 columns

Wouldn't that request fit perfectly into your goal of having one json datasource for all kinds of databases? Personally I believe it would expand the use case of your datasource by factors.

from grafanajsondatasource.

@andig I must somehow reconfigure the stale bot ;) But I wouldn't add wontfix, there's nothing to fix here, it's just a feature request everyone can implement.

@wernerdaehn just saying some kind of an option to do so is there.

Yes, the implementation would somehow look like you mentioned in 1.-4.

As I am new to Grafana, angular, datasource plugin development I was hoping to get some help. It should be quite simple for you, shouldn't it?

We're glad to help. You can always ask qustions and your PR receives a proper review.

Wouldn't that request fit perfectly into your goal of having one json datasource for all kinds of databases? Personally I believe it would expand the use case of your datasource by factors.

The goal is to completely abstract from database concept, it doesn't matter what runs in the background and that was already achieved by Simple JSON Datasource (and this one as well ofc) IMO.

from grafanajsondatasource.

Okay, will try.
It seems we have the same goals but a different understanding.
Do you agree that a timeseries-query always has one metric and a timestamp?
Do you agree that a table-query usually has many columns, regardless of what the backend is?
Do you agree that Grafana is not suited to render a table with lots of columns?
Do you agree that from the above we can derive that some kind of UI is needed for the user to choose what columns the table should show?
Why does every database datasource, MySQL, ElasticSearch,... have a query panel to control the list of columns in the table? If you want to abstract that, we need a selection box, don't we?

I really don't want to bother you, I am just trying to understand why we have the same goal but different opinions on this fact here. If you are saying I give a damn about table queries, then I will shut up and proceed on my own. But if you are like me and thriving for perfection, then.... ;-)

from grafanajsondatasource.

I really don't want to bother you

You're not ;)

If you are saying I give a damn about table queries

No, table queries are important,

I'll try to answer your questions later ASAP

from grafanajsondatasource.

Good points. Let me digest that.

from grafanajsondatasource.

I have created a fork with branch.
https://github.com/wernerdaehn/grafana-json-datasource/tree/tablecolumnselector

My first problem is how to set the private variable.

This line
https://github.com/wernerdaehn/grafana-json-datasource/blob/tablecolumnselector/src/query_ctrl.ts#L41
is obviously nonsensen as the request returns $$status future, not the data. In JS I would use a callback in the post request but what is the standard way for angularjs and grafana??

The query returns at the moment:

[{"name":"STREET","enabled":true},{"name":"COUNTRY","enabled":true},{"name":"REGION","enabled":true}]

from grafanajsondatasource.

That's weird, the rest of the code looks like it returns actual data. Eg. see wernerdaehn@1b656d1#diff-d08c5e2aaf65d640a9e2fce1af5b062cR108. result.data.map are immediatelly remapped .

from grafanajsondatasource.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

from grafanajsondatasource.