Filtry daty w Superset: obejście otoczki

Hack filtrów daty w wirtualnych zestawach danych Apache Superset

W Apache Superset wirtualne zestawy danych często wymagają dostosowania dat z filtrów pulpitu. Filtry automatycznie otaczają zapytania SQL dodatkowymi warunkami, co niszczy logikę. W wersjach poniżej 5 istniał makro remove_filter, ale teraz go nie ma. Rozważmy przypadki: trzeba dodać 3 dni do daty z filtra from_dttm.

Tworzymy wirtualny zestaw danych:

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

Dodajemy wykres "tabela" na pulpit z filtrem "ostatni tydzień". Superset otacza zapytanie warunkami typu ts >= '...' AND ts < '...', ignorując naszą modyfikację +3 dni. Filtrowanie działa niepoprawnie.

Analiza zachowania makr filtrów

Makra from_dttm i to_dttm zwracają:

• None (Python None), jeśli filtr jest pusty.
• Ciąg z datą w formacie TIMESTAMP, jeśli wartość została ustawiona.

Sprawdźmy to, tymczasowo uprościwszy zapytanie:

select {{from_dttm}} as res

Bez filtra: None. Z filtrem: '2026-03-23 00:00:00'. To klucz do rozwiązania — używamy default dla wartości None.

Uniwersalny trik: fałszywa kolumna

Przechwytywujemy wartości filtrów w zmiennych Jinja2 z domyślną wartością, tworzymy fałszywą kolumnę DATETIME. Synchronizuje się ona z zestawem danych i służy jako źródło filtrów na pulpicie.

Podstawowe zapytanie:

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

Po zapisaniu:

• Synchronizuj metadane zestawu danych.
• Sprawdź typ kolumny fict_column — powinien być DATETIME.
• Na pulpicie wskaż fict_column jako KOLUMNĘ DATY w filtrze.

Zewnętrzne warunki Superset (fict_column >= from_dttm AND fict_column < to_dttm) są zawsze spełnione, ponieważ from_dttm_fv pochodzi z filtra.

Rozszerzenie na to_dttm i niestandardowa logika

Przechwyć obie wartości:

{% 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')

Teraz:

• Warunki zewnętrzne dla fict_column są spełnione.
• Logika wewnętrzna stosuje przesunięcie +3 dni do ts.
• Filtrowanie na pulpicie działa poprawnie.

Krok po kroku: typowy proces konfiguracji

• Określ potrzebną modyfikację daty (przesunięcie, zaokrąglenie).
• Przetestuj makra: sprawdź wartości None i rzeczywiste daty.
• Stwórz fałszywą kolumnę z domyślną wartością.
• Synchronizuj zestaw danych, sprawdź typ DATETIME.
• Skonfiguruj filtr na kolumnie fict_column.
• Zastosuj niestandardową logikę w klauzuli WHERE.
• Zweryfikuj działanie na pulpicie.

Co jest ważne

• Fałszywa kolumna jest obowiązkowa: zapewnia prawdziwość zewnętrznych warunków Superset.
• Domyślna wartość dla None jest krytyczna: '1970-01-01 00:00:00' zapobiega błędom.
• Kastowanie do TIMESTAMP: gwarantuje typ DATETIME w metadanych.
• Synchronizacja metadanych: bez niej kolumna nie będzie widoczna w filtrach.
• Uniwersalność: działa dla dowolnych modyfikacji from_dttm/to_dttm.

To podejście pozwala całkowicie kontrolować daty w wirtualnych zestawach danych bez konfliktu z filtrami pulpitu.

— Editorial Team