Last tested: Sep 9, 2019
A PDT that has been created/modified in a user's dev mode has the following properties:
- It behaves as if it has
persist_for: 24 hoursregardless of what persistence is set.
- Each one will be its own table in the scratch schema (see "Why are there multiple copies of the same PDT in my database?").
Dev mode PDTs will NOT show in the Admin > PDT panel.(see below comment!)
- If you rebuild derived tables and run from your dev mode and the production SQL is exactly the same, then the prod version will be replaced.
- There is --if dev and --if prod syntax that allows you to modify the SQL in dev mode vs. production
- Dev mode PDTs with a
sql_trigger_valuewill have an epoch timestamp on them in the hash (prod PDTs with a
- Dev mode PDT builds will show up in the i__looker pdt_log explore with an Action Data of
expires at: [timestamp]where [timestamp] is 24 hours after the build completes (as it would show for a PDT with
persist_for: 24 hours).
UPDATE: As of 21.12, Dev Mode PDTs WILL show up in the Admin → PDTs panel: https://docs.looker.com/relnotes#pdt_development_mode_visibility
From what I have experienced in dev mode--
persist_forwill still be dropped after user-specified time (though I’ve only tested time that is less than 24 hours), whereas
*_triggerwill behave as
persist_for: 24 hours
I had issue with stale data in dev mode when I used
*_triggerbut not when I used
persist_for, if I click “clear cache and refresh”; I do not have permission to manually rebuild PDTs