[pie-chart] Restricting query to single metric

[john-bodley]

The pie chart should only allow specifying one metric in the UI. It always uses the first metric if multiple are specified, though this PR simply enforces the single metric UI component.

to: @williaster @GabeLoins @mistercrunch

[codecov-io]

Codecov Report

Merging #5203 into master will increase coverage by 0.06%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #5203      +/-   ##
==========================================
+ Coverage   63.39%   63.45%   +0.06%     
==========================================
  Files         261      261              
  Lines       19838    19838              
  Branches     1995     1995              
==========================================
+ Hits        12577    12589      +12     
+ Misses       7252     7240      -12     
  Partials        9        9

Impacted Files	Coverage Δ
superset/assets/src/explore/visTypes.js	62.5% <ø> (ø)	⬆️
superset/models/core.py	86.54% <0%> (+0.18%)	⬆️
superset/views/core.py	74.66% <0%> (+0.22%)	⬆️
superset/db_engine_specs.py	53.71% <0%> (+1.32%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 4b7a14d...11bfdbc. Read the comment docs.

[williaster]

LGTM 🚢

[mistercrunch]

I think it used to allow multiple metrics or one metric along with a groupby.

People may have metrics like boys and girls as different columns in their table.

[mistercrunch]

Also I'm pretty sure this will break existing charts. I think this would require a db migration moving the form_data from metrics to metric and selecting the first position of the array

[john-bodley]

@mistercrunch the pie-chart simply uses the first metric (so it works for metrics) which is the same behavior as the country-map (as well as others) and this is also configured using the metric (singular) field.

It seems there are multiple metric-keys supported, including metric and metrics. I've added a migration to ensure consistency, i.e., metric in the form-data translates to metric in the viz-type.

Note @mistercrunch I'm not sure what the policy is around form-data attributes but for the migration I simply remove the attribute (to prevent bloat) rather than storing None or [].

[mistercrunch]

LGTM, sorry about the confusion.

About how to deal with empty form_data or form_data key that match their default value is we should save all of the keys defined for that chart type at that point in time. That way if the default value changes the chart would still look the same. In some cases, null or [] may actually be different from the default, so we should save whatever the value is.

In this case here there should always be one metric so the db migration is fine.