-
Notifications
You must be signed in to change notification settings - Fork 14.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: add chart id and dataset id to global logs #26443
feat: add chart id and dataset id to global logs #26443
Conversation
b4f77bb
to
887ee8e
Compare
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #26443 +/- ##
=======================================
Coverage 69.48% 69.49%
=======================================
Files 1894 1895 +1
Lines 74151 74194 +43
Branches 8243 8243
=======================================
+ Hits 51527 51563 +36
- Misses 20555 20562 +7
Partials 2069 2069
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
superset/utils/decorators.py
Outdated
|
||
# limit data that can be saved to logs_context | ||
# in order to prevent antipatterns | ||
available_logs_context_keys = [ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it make sense for this to be a parameter? Right now this is hard coded for query related logging, but it might be useful for other logging purposes.
If we add the available_logs_context_keys
as a parameter when the decorator is called we can still keep the functionality of limiting data but for that specific call.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, that's a good question. In the SIP review we talked about trying to limit antipatterns of people putting random data into global context so the intention here is to use this list to limit what data can be passed in with the decorator, but there are definitely a lot of other use cases. I have three others on my todo list. I would suggest that if you think there's more data that should be considered for logging, then add it to the list in a PR and we'll see if it fits. That way we're still limiting the data that the decorator can accept, but we're not completely limited to just the set that is here now. How does that sound?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey Elizabeth, that sounds great! As for now there's no other data we need aside from dataset_id/slice_id so this is good on our end. Was just pointing this out as a future suggestion.
887ee8e
to
5677b80
Compare
5677b80
to
648b8c6
Compare
superset/charts/data/api.py
Outdated
context_func=lambda self, form_data: { | ||
"dataset_id": form_data.get("datasource", {}).get("id") | ||
if isinstance(form_data.get("datasource"), dict) | ||
and form_data.get("datasource").get("type") == DatasourceType.TABLE.value | ||
else None, | ||
"slice_id": form_data.get("form_data", {}).get("slice_id"), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we move this to a separate function to increase readability?
(cherry picked from commit 78dc6ce)
SUMMARY
part two of the context logs, this adds the chart and dataset ids to global context when the /data endpoints are called for use in the sql mutator.
An example of a sql_mutator override to log these values would be:
BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF
After with the mutator above:
TESTING INSTRUCTIONS
Update the sql mutator override, load a dashboard and click "view query" on a chart.
ADDITIONAL INFORMATION