hughhhh commented on code in PR #42284: URL: https://github.com/apache/superset/pull/42284#discussion_r3657980941
########## superset/common/form_data_query_context.py: ########## @@ -0,0 +1,227 @@ +# Licensed to the Apache Software Foundation (ASF) under one +# or more contributor license agreements. See the NOTICE file +# distributed with this work for additional information +# regarding copyright ownership. The ASF licenses this file +# to you under the Apache License, Version 2.0 (the +# "License"); you may not use this file except in compliance +# with the License. You may obtain a copy of the License at +# +# http://www.apache.org/licenses/LICENSE-2.0 +# +# Unless required by applicable law or agreed to in writing, +# software distributed under the License is distributed on an +# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +# KIND, either express or implied. See the License for the +# specific language governing permissions and limitations +# under the License. +""" +Synthesize a query context from a chart's saved form data (``params``). + +A chart's ``query_context`` is normally generated client-side by each viz +plugin's ``buildQuery`` and only persisted when the chart is (re-)saved in +Explore. Charts that predate that behavior keep their ``params`` (form data) but +carry no ``query_context``, so server-side consumers that need to run the query +(e.g. the dashboard Excel export) have nothing to execute. + +This module rebuilds a best-effort query context from the form data — columns, +metrics, filters (including free-form SQL and the time range), ordering and time +grain — mirroring the shared parts of the viz plugins' ``buildQuery``. It does +**not** reproduce plugin post-processing (pivot, contribution/percent +transforms, rolling/forecast) or multi-query fan-out, so callers must restrict it +to viz types whose data maps faithfully to a single plain query. +""" + +from __future__ import annotations + +from typing import Any + +from superset.utils import json + + +def adhoc_filters_to_query_filters( + adhoc_filters: list[dict[str, Any]], +) -> list[dict[str, Any]]: + """ + Convert ``SIMPLE`` adhoc filters into QueryObject filter clauses. + + Adhoc filters use ``{subject, operator, comparator}`` while a query object + expects ``{col, op, val}``. Only ``SIMPLE`` WHERE-clause filters are + convertible here; free-form ``SQL`` filters have no ``{col, op, val}`` + equivalent and are handled separately (see :func:`freeform_where_having`). + """ + result: list[dict[str, Any]] = [] + for flt in adhoc_filters or []: + if ( + flt.get("expressionType") == "SIMPLE" + and (flt.get("clause") or "WHERE").upper() == "WHERE" + ): + result.append( + { + "col": flt.get("subject"), + "op": flt.get("operator"), + "val": flt.get("comparator"), + } + ) + return result Review Comment: Reverted in 53350ae4c9 — `adhoc_filters_to_query_filters` again converts **all** SIMPLE filters regardless of clause, so SIMPLE HAVING filters the MCP compile/preview path relied on are no longer dropped. Added a test pinning that a SIMPLE HAVING filter still converts. (Note: the frontend `processFilters` does drop SIMPLE-HAVING, but preserving the prior shared behavior here is the safer choice and keeps MCP unchanged.) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
