feat(core): add extra form data fields for native filters#992
feat(core): add extra form data fields for native filters#992villebro merged 3 commits intoapache-superset:masterfrom
Conversation
|
This pull request is being automatically deployed with Vercel (learn more). 🔍 Inspect: https://vercel.com/superset/superset-ui/DwsZGbJXg2xVALdsEvXbQYxirjee |
c3ad624 to
483b1e2
Compare
Codecov Report
@@ Coverage Diff @@
## master #992 +/- ##
==========================================
- Coverage 27.94% 27.88% -0.07%
==========================================
Files 413 413
Lines 8523 8515 -8
Branches 1204 1201 -3
==========================================
- Hits 2382 2374 -8
Misses 5987 5987
Partials 154 154
Continue to review full report at Codecov.
|
This is long overdue! I still have a hard time wrapping my head around every time I see |
| adhoc_filters: AdhocFilter[]; | ||
| } = { | ||
| filters: [...(formData.filters || []), ...(append_form_data.filters || [])], | ||
| adhoc_filters: [...(formData.adhoc_filters || []), ...(append_form_data.adhoc_filters || [])], |
There was a problem hiding this comment.
I think better use ??... to do all like:
...(formData.filters ?? [])
There was a problem hiding this comment.
filters: [].concat(extras.filters, append_form_data.filters).filter(Boolean)I think this would be both faster and safer?
|
|
||
| const extras = extractExtras(formData); | ||
| // collect all filters for conversion to simple filters/freeform clauses | ||
| const filterFormData: { |
There was a problem hiding this comment.
2 questions:
- Should this functionality to be in
extractExtras? - Should we add here also
filters and adhoc_filtersfromcustom_form_data and override_form_data?
There was a problem hiding this comment.
extractExtrasandprocessFiltersprobably need to be slightly refactored now that there's more stuff going on here, but since this code is slightly convoluted I prefer to keep these changes as small as possible for now. Let's do a proper refactor soon when we know the full scope of changes required by native and cross filters.- I don't think we should to allow overriding filters, as it could break charts, but happy to open up this discussion if there are known use cases for it. Also,
custom_form_dataprobably shouldn't includefiltersandadhoc_filters, as those are already defined inQueryFormDataandQueryObject.
There was a problem hiding this comment.
About 2. For example what will be behavior for a case:
I have table with server pagination and cross filtering:
- User clicks
Page 2we have incustom_form_datadata about server pagination - We have button in dashboards like
resetDashboardso we need reset it toPage 1or stuff like that
simcha90
left a comment
There was a problem hiding this comment.
approve, but some questions left
05d6541 to
8c46beb
Compare
ktmud
left a comment
There was a problem hiding this comment.
LGTM with some questions. Looking forward to further cleanups in this area.
| adhoc_filters: AdhocFilter[]; | ||
| } = { | ||
| filters: [...(formData.filters || []), ...(append_form_data.filters || [])], | ||
| adhoc_filters: [...(formData.adhoc_filters || []), ...(append_form_data.adhoc_filters || [])], |
There was a problem hiding this comment.
filters: [].concat(extras.filters, append_form_data.filters).filter(Boolean)I think this would be both faster and safer?
| sqlExpression: '(1 = 1)', | ||
| }, | ||
| ], | ||
| }, |
There was a problem hiding this comment.
Question about adhoc_filters and filters. Is my understanding correct that filters are only used for native filters and can only be set from append_form_data, since all filters defined in chart formData are basically adhoc_filters?
I'm a little confused why do we need to allow appending and overriding both filters and adhoc_filters. The overrides are only from a Dashboard's native/cross filters, which would be only in QueryObjectFilterClause or QueryFormExtraFilter format.
It seems to me the original design of an adhoc_filters vs extra_filters was cleaner.
Not sure if this is the direction of future refactoring, but we probably shouldn't add extra stuff that are not configurable by chart controls to formData. This extra_form_data could be moved to the extra options of buildQueryObject and buildQuery. E.g.
buildQueryObject(formData, {
queryFields: ... // configured in chart metatada,
extraFormData: {
append: {
adhoc_filter: [...],
},
override: {
}
} // collected from dashboard state
});There was a problem hiding this comment.
AFAIK filters are just the simple filters that preceeded adhoc_filters (before my time). I'm not sure why we support both, as adhoc_filters are a superset of filters, but my assumption is it's a leftover from old times. I've been using the filters property when adding filters that are simple, i.e. don't require custom SQL, but we could equally well ditch filters and just make it possible append to adhoc_filters.
There was a problem hiding this comment.
We should probably:
- Rename the Python attribute
query_object.filtertoquery_object.filters - Rename
adhoc_filterson the client side tofiltersand have it support both simple filter and adhoc filters. - Move the filter format consolidation logic to the server side. Either in QueryObject itself or when actually building the SQL queries.
8c46beb to
cfe6de8
Compare
cfe6de8 to
555dd3b
Compare
4294d4f to
f01b2ae
Compare
e6518b3 to
fba64d3
Compare
fba64d3 to
bd02652
Compare
…erset#992) * feat(core): implement time grain and column filters * add apply_fetch_values_predicate to QueryObject * clean up extract types and fix tests
🏆 Enhancements
List of changes:
time_grainandtime_columnfields toQueryFormDatato get ready to streamlinegranularity,granularity_sqlaandtime_grain_sqla.appendExtraFormData, as we should only enable appending filters (are handled byprocessFilters.tsnow to centralize filter handling inbuildQueryObject)buildQueryContext.ts