feat(jinja): metric macro

[Vitor-Avila]

SUMMARY

This PR adds a new Jinja macro: {{ metric('metric_key', dataset_id) }}. This macro can be used to retrieve metric syntax from a dataset, to be re-used in charts/SQL Lab/etc.

This is useful to avoid copy/paste and provide a centralized place for metric management. Some use-cases:

• Overwriting a metric label in the chart level: Users can use the macro as a custom SQL metric to define a different label in the chart without changing the dataset configuration.
• Combining metrics: Users could combine metrics (for example {{ metric('revenue') }} - {{ metric('cost') }}.
• Using metrics in SQL Lab: Retrieve the metric syntax in SQL Lab for ad-hoc querying.
• Reusing metrics across datasets: When creating virtual datasets that are "variations" of a curated physical dataset, this macro can help retrieving metric syntax syntax from the curated dataset into the virtual one.

The dataset_id parameter is optional and if not provided Superset will attempt to get it from the current context.

I also noticed there were both test_jinja_context.py and jinja_context_test.py, so I unified the two.

BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF

After

Video attached to Google Drive (Exceeds 10MB)

TESTING INSTRUCTIONS

Both unit and integration tests added. For manual testing:

1. Create a metric in any dataset.
2. Create a chart using this dataset.
3. Define a metric using custom SQL: {{ metric("metric_key") }}, replacing metric_key with the key used to create the metric in step 1.

ADDITIONAL INFORMATION

• Has associated issue:
• Required feature flags: ENABLE_TEMPLATE_PROCESSING.
• Changes UI
• Includes DB Migration (follow approval process in SIP-59)
  • Migration is atomic, supports rollback & is backwards-compatible
  • Confirm DB migration upgrade and downgrade tested
  • Runtime estimates and downtime expectations provided
• Introduces new feature or API
• Removes existing feature or API

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 69.85%. Comparing base (f274c47) to head (98d8979).
Report is 1393 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master   #27582      +/-   ##
==========================================
+ Coverage   67.46%   69.85%   +2.38%     
==========================================
  Files        1910     1911       +1     
  Lines       74802    74982     +180     
  Branches     8345     8345              
==========================================
+ Hits        50467    52375    +1908     
+ Misses      22284    20556    -1728     
  Partials     2051     2051              

Flag	Coverage Δ
hive	48.92% <6.89%> (?)
mysql	77.88% <65.51%> (-0.14%)	⬇️
postgres	78.02% <65.51%> (-0.12%)	⬇️
presto	53.64% <6.89%> (?)
python	83.14% <100.00%> (+4.87%)	⬆️
sqlite	77.46% <65.51%> (-0.12%)	⬇️
unit	56.77% <100.00%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[dpgaspar]

this could be None

[Vitor-Avila]

that's a good catch! I was thinking that you must associate a dataset to a chart when creating one, but forgot it could be deleted after. Improved that if chart to if chart and chart.datasource_id to avoid returning None.

On the second part tho (with the walrus operator) if url_params["datasource_id"] is None, this if block condition won't be met and therefore it won't return. I added a test case covering this specific scenario.

[dpgaspar]

chart_id could be None

[Vitor-Avila]

Similarly, the walrus operator condition here shouldn't be met so we wouldn't return None. Also added a test case for this scenario.