Last Tested: Jan 31, 2022
PDT name structure:
All PDT names begin with LR, short for Looker Read. The
connection_key is a two letter string that is unique for the connection. The PDT hash is an encoding slug that follows the
connection_key and precedes
view_name in the SQL table name. (ex: if the PDT SQL table name is
LR$ZLYI79XRAB6OU1633ET9D_CS_HEALTH_CALENDAR_DAILY, the connection_key is
ZL and the hash is
The PDT hash encodes the following information:
- Scratch Schema
- Instance Slug
- Underlying LookML
- View Name
- Datagroup name, if used
- SQL of the sql_trigger/sql_trigger_value, if used
- Underlying SQL of the PDT (including SQL of dependencies)
- Increment Key
- Creation Timestamp
Since the hash includes the creation timestamp, the PDT name changes every time it is rebuilt, with the exception of incremental PDTs. With incremental PDTs, the PDT name remains the same upon each incremental rebuild, unless there is a change to the underlying LookML (e.g. change to the increment key).
Note: The above hash refers to the hash in the PDT table name, which differs from the PDT hash. The PDT hash does not include the creation timestamp and therefore does not change each time a PDT rebuilds.
Is it possible to reorder this PDT naming convention?
This naming convention is inconvenient for querying outside of the Looker environment. For example, in BigQuery it is possible to query tables using a wildcard, however, only in the case where the wildcard exists at the end of the table name:
Works: SELECT * FROM <project_id>.<dataset>.<pdt_name>_LR_*
Doesn’t Work: SELECT FROM <project_id>.<dataset>.LR_*_<pdt_name>
publishing the pdt as a db view does not work in the case where the pdt is generated using “persist for” in the derived table lookml
I have the same question as
@atea as I am trying to build a table of top performers based on another PDT (defining what to take as a performer unit) and it breaks each time the underlying PDT name gets updated with a timestamp.
@thomas.banghart that is exactly what I needed.