Looker Connect Training

Help Center

Documentation

Community

Cloud Certifications

Removing PDTs from the scratch Schema

  • 23 March 2015
  • 4 replies
  • 890 views
Zam
Userlevel 4
Badge

The way to delete a PDT is to remove any reference of it from your model, or models if you have multiple models in one project. Once you’ve removed any references to the PDT, Looker will drop the PDT in it’s next table clean up process.



There are a few ways to properly remove the reference to the PDT.



First make sure to remove/comment out all joins for this PDT. If you don’t, the LookML validator will throw a bunch of errors.



Then do one of the following:







  • Comment out all lines in the PDT’s view file.







  • Replace any - include: *.lookml statement with explicit includes for each view file excluding the PDT’s view file. Since PDTs have a distinct table for each model file they are included in, this is the best method if you want a PDT to only be used in one of your models.







  • Delete the PDT view file (probably not best since you may want to use the PDT at a future date).





4 replies

J

We had a situation in which multiple versions of the same file were created. The problem appeared to be because several models in the project included the view, but it used a datagroup_trigger defined in one model. A Looker bug causes this to create one file for the model that housed the datagroup, and another copy associated with the other models.


The obvious problem is that the table is being built and regenerated twice every time. It’s stored twice, appears in lists twice, etc. Deleting one copy by hand was not effective, as both copies have the exact same name, so all the references to it still existed. (Looker actually regenerated the whole file from whole cloth; we don’t know how.)


The less obvious problem is that the pairs of files are not entirely identical, based on when the datagroup was created and when they actually regenerated. It’s very difficult (if possible at all) to tell which version a query is speaking to, since for reference purposes they share the exact same name.

izzy
Userlevel 7
Badge +1

That’s definitely confusing, Jon. When you say “file”, you’re referring to the temporary PDT table in your database, right?


I’ve seen the behavior before of a PDT-view-file being included in multiple models leading to multiple tables being built. That said, I wonder what the best way to do this would be…


It’s kind of an interesting puzzle— You obviously don’t want multiple PDTs to be generated that are identical (or near identical), but you also want models to be able to be stand alone, and it kind of makes sense that if you include a view file in multiple models, it will treat those independently, since most everything in looker (permissions, etc.) happens at the model level, not the view level or even the project level.


I think there’s definitely some complexity for us to think about there though, and maybe come up with a better implementation. What’d your ideal behavior look like?

J

Hi Izzy,


I would only want one copy of the pdt to exist, regardless of models that were including it. I would think that this is standard, reasonable, expected behavior. If we wanted each model to have different versions, then each model would have its own LookML code for that pdt (and we’d give it different names, so it wouldn’t really be the same pdt). Also, if the intention is for models to function separately, then why would all the other models that include the view file generating the pdt share just one copy?


We have one view file and one name. The expectation is that this will generate one identical table, not more. A side benefit of it generating just one table with the same name would be that when you reference it, you would know which version of the table you were referencing. (It would be the only version.)

izzy
Userlevel 7
Badge +1

This is a very good point and a good reason to have your ideal behavior be standard— That kind of ambiguity is a recipe for confusion.


A colleague mentioned to me that she’s already working on this with you through support channels. I’m going to let them drive this from there, since they’re definitely better equipped to do this kind of in depth troubleshooting as well as getting things in front of engineering.


Thanks for dropping a note here, though, and feel free to keep updating— I’m curious!

Reply


Terms of Service