Elegantly Handling 'Unknown or Inaccessible Field' Scenarios


(Noah) #1


I am looking to add more flexibility to the future modeling of the views that depend on other views/joins for fields. I am getting an error related to a field that is referencing a join that may or not exist. While I would prefer to have the option to pass a value agnostic of a specific view field or filter name (like ${table.parameter_name} = ${base_table.basetablecolumn}) I will just stick to referencing a particular view field. That leads us to some future scenarios where the view may be modeled in a way that shows an error as discussed here. Only solutions appear to be either exclude the fields with dependencies or join it.

Besides excluding the field(s) by doing something like requiring all non-dependent fields be listed in a set for easy future reference, is there something I can do to wrap a ‘unknown or inaccessible field’ error parameter for those non-utilized scenarios? It would be nice to say something like “permit_null=true” and to handle a reference elegantly with IFNULL or some other dialect-specific NULL handling function. If that option doesn’t exist are there any other solutions?

Update: I am seeing this discussion here. The discussion is a little dated so I should more ask- are there any more recent updates that we can take advantage of?

(Aleksandrs Vedernikovs) #2

Hi @_Noah,

I hope you are doing good. Thanks for bringing this up. I am totally with you that this can be frustrating sometimes and I am happy to pass your feedback to our Product team. At the moment there is no any other mechanism in Looker to catch it.
What Lloyd said usually does the trick ; move the offending fields to bare joins.



(lloyd tabb) #3

One way I’ve handled this is to use extends. You can declare a view with your isolated calcuations. You can extend the view and place your extended calculations that require joins in another view. In your explore you can pick the appropriate level.

explore: users {}
explore: orders {
  joins: users {
    from: users_with_orders

# The simple basic definition of users
view: users {..}

# The version of users to use when orders is joined in
view: user_with_orders {
   extends: [users]
   dimension: some_calc {
   sql: ${TABLE}.some_calc + ${orders.other_calc}

(Noah) #4

@lloydtabb Good idea. I will look to see how we can include this in our standardizing of views with dependencies.