Knowledge Drop

Dev Mode PDTs

Userlevel 5

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 hours regardless 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_value will have an epoch timestamp on them in the hash (prod PDTs with a sql_trigger_value will not).
  • 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).


This content is subject to limited support.                


2 replies

Userlevel 2

UPDATE: As of 21.12, Dev Mode PDTs WILL show up in the Admin → PDTs panel:

From what I have experienced in dev mode--


  • PDTs with persist_for will still be dropped after user-specified time (though I’ve only tested time that is less than 24 hours), whereas
  • PDTs with *_trigger will behave as persist_for: 24 hours


I had issue with stale data in dev mode when I used *_trigger but not when I used persist_for, if I click “clear cache and refresh”; I do not have permission to manually rebuild PDTs