Datumsfilter in Superset: Umgehung des Wrappers

Datumsfilter in Apache Superset Virtual Datasets umgehen

In Apache Superset müssen virtuelle Datensätze oft mit benutzerdefinierten Datumsmanipulationen ausgestattet werden, die von Dashboard-Filtern abhängen. Filter fügen automatisch zusätzliche Bedingungen zu SQL-Abfragen hinzu, was Ihre ursprüngliche Logik untergräbt. Obwohl die remove_filter-Makro in Versionen vor 5 existierte, ist es nicht mehr verfügbar. Schauen wir uns ein typisches Szenario an: Hinzufügen von 3 Tagen zum Wert des from_dttm-Filters.

Erstellen Sie einen virtuellen Datensatz mit dieser Abfrage:

select *   from messages   where 1=1   and ts > (TIMESTAMP '{{ from_dttm | default("1970-01-01", true) }}' + INTERVAL '3 days')

Fügen Sie ein "Tabelle"-Chart mit dem Filter "Letzte Woche" hinzu. Superset umschließt die Abfrage mit Bedingungen wie ts >= '...' AND ts < '...', wodurch Ihre +3 Tage-Anpassung ignoriert wird. Die Filterung funktioniert falsch.

Verständnis des Filter-Makro-Verhaltens

Die Makros from_dttm und to_dttm geben zurück:

• None (Python None), wenn der Filter leer ist.
• Ein Zeitstempel-String (z. B. '2026-03-23 00:00:00'), wenn ein Wert gesetzt ist.

Testen Sie dies, indem Sie die Abfrage vorübergehend vereinfachen:

select {{from_dttm}} as res

Ohne Filter: None. Mit Filter: '2026-03-23 00:00:00'. Dies ist der Schlüssel – verwenden Sie default, um None-Werte zu behandeln.

Universelle Lösung: Die Fake-Spalte-Strategie

Speichern Sie Filterwerte in Jinja2-Variablen mit einem Standardwert, erstellen Sie eine künstliche DATETIME-Spalte. Diese Spalte synchronisiert sich mit dem Datensatz und bildet die Grundlage für die Dashboard-Datumsfilterung.

Grundabfrage:

{% set from_dttm_fv = from_dttm | default("1970-01-01 00:00:00", true) %}   SELECT *, '{{ from_dttm_fv }}'::TIMESTAMP as fict_column   FROM messages

Nach dem Speichern:

• Synchronisieren Sie die Datensatz-Metadaten.
• Stellen Sie sicher, dass fict_column vom Typ DATETIME ist.
• Legen Sie in der Dashboard-Filterung fict_column als Zeitspalte fest.

Superset’s externe Bedingungen (fict_column >= from_dttm AND fict_column < to_dttm) evaluieren immer zu true, da from_dttm_fv direkt aus dem Filter entnommen wird.

Erweiterung auf to_dttm und benutzerdefinierte Logik

Speichern Sie beide Filterwerte:

{% set from_dttm_fv = from_dttm | default("1970-01-01 00:00:00", true) %}   {% set to_dttm_fv = to_dttm | default("1970-01-01 00:00:00", true) %}   SELECT *   , '{{ from_dttm_fv }}'::TIMESTAMP as fict_column   FROM messages   WHERE ts > (TIMESTAMP '{{ from_dttm_fv }}' + INTERVAL '3 days')   and ts < (TIMESTAMP '{{ to_dttm_fv }}' + INTERVAL '3 days')

Jetzt:

• Externe Bedingungen auf fict_column sind immer erfüllt.
• Interne Logik wendet den +3 Tage-Shift auf ts an.
• Die Dashboard-Filterung funktioniert korrekt.

Typischer Einrichtungsworkflow

• Definieren Sie die erforderliche Datumsanpassung (Verschiebung, Rundung).
• Testen Sie die Makros: Bestätigen Sie das Verhalten mit None und echten Werten.
• Erstellen Sie eine künstliche Spalte mit default.
• Synchronisieren Sie den Datensatz und überprüfen Sie den DATETIME-Typ.
• Konfigurieren Sie im Dashboard den Filter, um fict_column zu nutzen.
• Wenden Sie benutzerdefinierte Logik im WHERE-Klausel an.
• Validieren Sie die Ergebnisse im Dashboard.

Wichtige Erkenntnisse

• Künstliche Spalte ist zwingend erforderlich: sorgt dafür, dass Superset’s externe Bedingungen immer erfüllt sind.
• None-Standard ist entscheidend: 1970-01-01 00:00:00 vermeidet Laufzeitfehler.
• Verwenden Sie ::TIMESTAMP-Cast: stellt sicher, dass der Typ im Metadaten-Store korrekt ist.
• Metadaten synchronisieren: ohne Synchronisation erscheint die Spalte nicht in den Filtern.
• Universelle Lösung: funktioniert für jede Datumsmanipulation bei from_dttm oder to_dttm.

Diese Methode bietet vollständige Kontrolle über die Datumsverarbeitung in virtuellen Datensätzen, ohne Konflikte mit Dashboard-Filtern.

— Editorial Team