Liquid checks in persistent derived tables: Triggered builds failed?

Hi,

My PDTs work fine unless the build is triggered by Looker instead of through an Explore.

I have the following PDT definition:

derived_table: {
sql:

{% if _explore._name != 'cross_channel' or cross_channel.facebook._parameter_value == '1' and _explore._name == 'cross_channel' %}

SELECT min(date_start) as fb_min_date, max(date_start) as fb_max_date
FROM ${facebook_ads.SQL_TABLE_NAME}

{% else %}
SELECT current_date as fb_min_date, NULL as fb_max_date
{% endif %};;

sql_trigger_value: SELECT MAX(date_start) FROM ${facebook_ads.SQL_TABLE_NAME} ;;
partition_keys: ["fb_min_date"]
}

The PDT works fine in the Expore view. I can see it being build when I run a query for the first time:

17902e72-3b00-4502-85dc-86090df1c592.png

And I can see it being used afterwards:

8d917d79-53ed-4d13-b842-f617395fa7ee.png

I also checked that the table is in BigQuery, where I can query it.

However, my PDT admin dashboard, is full of build errors, also for this specific example:

02d7b9a6-8c84-44d8-868d-223a520ea2ed.png

It looks like the Liquid syntax is causing an SQL error somehow:

7b4df1aa-ae8e-44a7-9211-9446d59f70ed.png

and that Looker doesn’t strip away the Liquid tags on triggered build:

ef6dec73-6d3c-487c-b1b8-174a78d939c1.png

These build errors pop up every 5 minutes, so I’m assuming it is because of the triggered build.

Any idea on how to solve this?

I was assuming that a triggered build would build versions of the PDT for each possible parameter combination but that doesn’t seem to be what’s happening.

Thanks!

2 1 382
1 REPLY 1

Top Labels in this Space
Top Solution Authors