Finalize DataQuery schema interface spec

[sdboyer]

Currently, the Query slot is wide open - no restrictions on what can be expressed by plugin authors:

grafana/pkg/kindsys/slots.cue

Lines 42 to 43 in 9d64e7c

	// Meta-schema for the Query slot, as implemented in Grafana datasource plugins.
	slots: Query: {...}

After conversation with @ryantxu, i now understand that realistically, there are two things that actually do need to be represented:

• Each datasource plugin may define multiple types of queries.
• Within existing dashboards, these are differentiated by the queryType field. The combination of datasource.type with queryType effectively form a discriminator for the type of query.

Needing to support multiple queries here is somewhat tricky. Naively, each of them would receive their own lineage, as they're generally unrelated objects (though sharing some elements isn't so uncommon). But i didn't design the slot system to accommodate multiple lineages per slot, and it's too late to change. That probably means that we're looking at something like this:

slots: queries: {
	[QT=string]: {
		queryType: QT
	}
}

This feels like yet another case for grafana/thema#62. That makes me squirmy, because it feels like leaning on that for this case is further stretching a useful hack in such a way where we really can't infer much about intended semantics generically in thema. But i see no way around it, so it's best to just embrace it as a constraint.

[sdboyer]

#61192 is going to have a solution that i think will settle this, but could change.

I came to the conclusion that the approach outlined in the OP is incorrect. While it is true that plugins can effectively support multiple query types, and this is a pattern we want to encourage within datasource plugins, my sense is that

• The current state of dashboard json wrt these fields
• The variability in implementation within existing datasources
• Lack of clarity around how grouped lineages in thema will work

All mean that it's too much of a reach to try to have this schema interface work with multiple members for each queryType, especially when i think we can get what we want by encoding a bit more rules onto the schema interface itself.

[frossano-grafana]

this is a good candidate for pairing with @sdboyer for someone in the team
Also moving out for Going public and to Stable maturity

[github-actions]

This issue has been automatically marked as stale because it has not had activity in the last year. It will be closed in 30 days if no further activity occurs. Please feel free to leave a comment if you believe the issue is still relevant. Thank you for your contributions!

[github-actions]

This issue has been automatically closed because it has not had any further activity in the last 30 days. Thank you for your contributions!