Skip to content

Conversation

@csmarchbanks
Copy link
Contributor

In recent versions of Grafana the datasource can be either a string or a
map with entries for type and uid. Support both of these cases by using
an interface which will allow backwards compatiblity.

Alternatively, I could change Datasource to a more concrete type that
can marshal/unmarshal from a string or map, but that would break anyone
just setting it to a string right now. Let me know what you think!

See grafana/grafana#33817 for more context on the
change in Grafana.

In recent versions of Grafana the datasource can be either a string or a
map with entries for type and uid. Support both of these cases by using
an interface which will allow backwards compatiblity.
@GiedriusS
Copy link
Collaborator

I am kind of hesitant to open the floodgates for more interface{}. Go with generics is just around the corner and with generics, we should be able to gently solve this problem by using union constraints (https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#union-constraint-element), right?

@csmarchbanks
Copy link
Contributor Author

I am OK with that, I can keep my branch open so that users who need this before generics are available/have not upgraded yet. I guess it really depends on how fast you want to move this library to generics.

@colega
Copy link
Contributor

colega commented Mar 10, 2022

Oh, I haven't seen this PR. I submitted a different one without generics but also without interface{}: #201

@telmich
Copy link

telmich commented Mar 20, 2022

Hey everyone! I was wondering whether this might be merged soon? This might solve mpostument/grafana-sync#43 which is blocking some parts for us.

@rdesgroppes
Copy link

Pretty please...

@safaci2000
Copy link
Contributor

@GiedriusS I gave the generics bit a go, but there's a few issues unless someone has some insight I think you may be limited to using interface or the Reference type that @colega introduced.

Here's my attempt at using it.

https://go.dev/play/p/Ogk59A6RHbC

The main issue I see is that you would have to know ahead of time what the data type is in order to serialize the code.

You'd likely have to create a

t := Board[map[string]string]{}
json.Unarmshall(json, t)

It fails to address the core of the issue which is we don't know if it'll be a map or a string. If anyone has any suggestion on how to use generics AND allow for nondeterministic behavior or the response i'm happy to try to add this in.

@thre3eye
Copy link

Just a heads-up that we're all still waiting :)

As far as I can tell the instructions on the main site won't work until a fix is pushed out https://grafana.com/docs/grafana-cloud/metrics-control-usage/control-prometheus-metrics-usage/usage-analysis-cortextool/

Thanks

@GiedriusS
Copy link
Collaborator

I'll take a look soon, a bit on vacation ATM.

@safaci2000
Copy link
Contributor

Any updates on this change?

@safaci2000
Copy link
Contributor

@GiedriusS any thoughts on this PR or alternate approaches you'd prefer?

Copy link
Collaborator

@GiedriusS GiedriusS left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's merge this as is and wait for proper sum type support in Go ;(

@GiedriusS GiedriusS merged commit 00edde0 into grafana-tools:master Jun 8, 2022
wurbanski pushed a commit to kubermatic/grafanasdk that referenced this pull request Sep 4, 2023
In recent versions of Grafana the datasource can be either a string or a
map with entries for type and uid. Support both of these cases by using
an interface which will allow backwards compatiblity.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants