apache/superset · error · QueryObjectValidationError

Drill to detail is not available for this datasource type.

Error message

Drill to detail is not available for this datasource type.

What it means

In query_actions drill-to-detail preparation, Superset checks getattr(datasource, 'supports_drill_to_detail', True) and hard-blocks the query with QueryObjectValidationError for datasource classes that opt out (e.g. semantic-layer/semantic views that don't model raw rows). This mirrors the supports_samples gate so drill-detail cannot be forced via the API even if the frontend hides it.

Source

Thrown at superset/common/query_actions.py:260

    query_obj.from_dttm = None
    query_obj.to_dttm = None
    return query_obj


def _prepare_drill_detail_query(
    query_context: QueryContext,
    query_obj: QueryObject,
) -> QueryObject:
    # todo(yongjie): Remove this function,
    #  when determining whether samples should be applied to the time filter.
    datasource = _get_datasource(query_context, query_obj)
    # Refuse for datasource types that don't model raw rows (e.g. semantic
    # views). Mirrors the ``supports_samples`` gate on the ``/samples``
    # endpoint so drill-detail is hard-blocked on the backend, not just
    # hidden in the frontend menu. Defaults to ``True`` for any datasource
    # class that doesn't explicitly opt out.
    if not getattr(datasource, "supports_drill_to_detail", True):
        raise QueryObjectValidationError(
            _("Drill to detail is not available for this datasource type.")
        )
    query_obj = copy.copy(query_obj)
    query_obj.is_timeseries = False
    query_obj.metrics = None
    query_obj.post_processing = []
    qry_obj_cols = []
    for o in datasource.columns:
        if isinstance(o, dict):
            if column_name := o.get("column_name"):
                qry_obj_cols.append(column_name)
        else:
            qry_obj_cols.append(o.column_name)
    query_obj.columns = qry_obj_cols
    query_obj.orderby = [(query_obj.columns[0], True)]
    return query_obj

View on GitHub (pinned to f4587218dd)

Solutions

  1. Use a datasource type that supports raw-row access (a physical dataset/table) for drill-to-detail.
  2. If you maintain a custom datasource class and it does expose rows, set supports_drill_to_detail = True on it.
  3. Remove/hide drill-to-detail UI affordances for charts on semantic datasources.

Example fix

# before (client)
result_type = "drill"  # against semantic-layer datasource

# after
if not getattr(datasource, "supports_drill_to_detail", True):
    result_type = "results"  # fall back to aggregated results
Defensive patterns

Strategy: validation

Validate before calling

if not getattr(datasource, "supports_drill_to_detail", True):
    raise ValueError("drill-to-detail unsupported for this datasource")

Type guard

def supports_drill(ds) -> bool:
    return bool(getattr(ds, "supports_drill_to_detail", True))

Try / catch

from superset.exceptions import QueryObjectValidationError
try:
    run_drill_query(qc)
except QueryObjectValidationError as e:
    if "Drill to detail" in str(e):
        fall_back_to_aggregated_results()

Prevention

When it happens

Trigger: POSTing a query context with result type that triggers drill-to-detail (or the drill-detail endpoint) against a datasource whose class defines supports_drill_to_detail = False, e.g. a QUERY/semantic-layer datasource.

Common situations: Using the 'View results'/'Drill to detail' UI or API on a chart built on a semantic view; custom datasource plugins that forgot to set the flag; API clients replaying drill-detail payloads against unsupported datasource types.

Related errors


AI-assisted analysis of apache/superset@f4587218dd (2026-08-14). Data as JSON: /api/errors/ee7fc6c4fda4b212. Report an issue: GitHub.