-
Notifications
You must be signed in to change notification settings - Fork 272
feat(core): add extra form data fields for native filters #992
feat(core): add extra form data fields for native filters #992
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think better use ??
... to do all like:
...(formData.filters ?? [])
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.
filters: [].concat(extras.filters, append_form_data.filters).filter(Boolean)
I think this would be both faster and safer?
@@ -42,8 +43,17 @@ export default function buildQueryObject<T extends QueryFormData>( | |||
const { metrics, columns, orderby } = extractQueryFields(residualFormData, queryFields); | |||
|
|||
const extras = extractExtras(formData); | |||
// collect all filters for conversion to simple filters/freeform clauses | |||
const filterFormData: { |
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.
2 questions:
- Should this functionality to be in
extractExtras
? - Should we add here also
filters and adhoc_filters
fromcustom_form_data and override_form_data
?
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.
extractExtras
andprocessFilters
probably 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_data
probably shouldn't includefilters
andadhoc_filters
, as those are already defined inQueryFormData
andQueryObject
.
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.
About 2. For example what will be behavior for a case:
I have table with server pagination and cross filtering:
- User clicks
Page 2
we have incustom_form_data
data about server pagination - We have button in dashboards like
resetDashboard
so we need reset it toPage 1
or stuff like that
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.
approve, but some questions left
05d6541
to
8c46beb
Compare
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.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should probably:
- Rename the Python attribute
query_object.filter
toquery_object.filters
- Rename
adhoc_filters
on the client side tofilters
and 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_grain
andtime_column
fields toQueryFormData
to get ready to streamlinegranularity
,granularity_sqla
andtime_grain_sqla
.appendExtraFormData
, as we should only enable appending filters (are handled byprocessFilters.ts
now to centralize filter handling inbuildQueryObject
)buildQueryContext.ts