PDT Naming: Development vs Production


(Jeff Lek) #1

Hi all,

I have a question that I haven’t been able to fully answer from the documentation: Is there way of distinguishing between PDT in the looker_stratch schema, that were created as part of the production system or by a develop in development mode? Somehow my schema only contains table with the “lr” prefix.

I found quite a few articles stating that different prefixes are used by Looker to indicate different table states, but it seems to me that this info might be outdated.

It would be great if someone could share the “current” logic of pdt naming with me.

Many thanks in advance,

(Ryan Dunlavy) #2

Hey @JeffLeROI,

The prefix for the table is determined by the current state the table is in, so if the table is currently being built it will have a prefix of LC for Looker Create, and if it is ready to be read it will have a prefix of LR for Looker Read. The “Understanding PDT Names” section of this discourse article has some more detail on the difference between these two.

Once the table is ready to read in production and in development mode, the table name will have the LR$ prefix followed by a longer hash, followed by the view name, like this:


If a sql_trigger_value is being used, during the creation step the name for PDTs built in dev mode will be slightly different. They will start with the LC$ prefix, have a short hash, then an epoch timestamp, then the view name, like this:


You can use this difference in the hash during the creation process to check where the tables came from in the i__looker pdt_log explore at /explore/i__looker/pdt_log

Once the PDTs are ready to read there isn’t a way to tell dev and production PDTs based on their name, so I’m going to pass that feedback along to the product team. Hope this helps!


(conrad) #3

Just a couple minor clarifications.

  • whether built in dev or production, the building table will have prefix of lc
  • we intentionally and very carefully use the same name for both production and dev mode tables when the lookml that affects the table computation is identical so that a table with identical schema/contents will not need to be rebuilt when querying in dev or promoting newly dev’d lookml to production. This has an unfortunate side effect of making it difficult to identify tables which are being built from dev lookml and are not compatible with production.
  • we do maintain a flag on the reference to each pdt which indicates whether it has been seen in production, and will be exposing this via i_looker in an upcoming release.