Model looking at a PDT even though it's excluded

(Menashe Hamm) #1

I’ve got a view view1 with a dimension dim1 that uses another PDT, pdt1, in its SQL. pdt1 is invalid only in one of our models, model1, but view1 is used in model1. Therefore, wherever view1 is used in model1, I made sure to explicitly exclude dim1 using fields:. Nonetheless, I’m getting this warning:

Persistent derived table pdt1 should include at least one index
model1 (model1:explore9)

This seems to be a bug. Or am I doing something wrong?

If it’s a bug, does anyone have a workaround?

(conrad) #2

Is it possible you are including the derived table view file (possibly with some wildcard include) in the model in which it should not be included
e.g. include: *.view.lookml? You might need to be more explicit about your includes.

(Menashe Hamm) #3

Thanks, @conrad, but no: the error here is that pdt1 is being included in an explore (explore9) in model1, even though I’ve specifically excluded it.

( #4

Hey Menashe,

This is a warning about missing index your table, and In almost all cases you will want to index your tables as it will increase performance when joining/scanning (filtering) the table.

The reason we warn is most likely to insist that performance could be optimised by adding indexes.

Adding an index to your table should stop this warning. >>

(Menashe Hamm) #5, some dialects support indexing, others don’t, and Looker is smart enough, usually, to know the difference. In this case, I’ve explicitly excluded this view from all explores where indexing is a possibility and, in particular, from explore9, where the warning is being thrown. Adding an indexes: parameter may hide the warning, so thank you for the workaround, but the warning shouldn’t be showing up even without indexes:.

(conrad) #6

@menashe I’d really like to get to the bottom of this. However, to understand the issue better, I’d need to see the model and view files in question (or some abstract of them). Please feel free to connect with support via chat to identify the specific modeling pattern which is causing problems and convey the info to our engineering team.

(Menashe Hamm) #7

Will do. Thanks!