Looker SQL derived tables doing dbt's job

This rule flags each Looker view built from a SQL derived table, a derived_table with sql: of its own. A native derived table built with explore_source is never flagged. A persisted one is rated higher, because Looker builds and stores it.

Logic here is invisible to dbt: not tested, not documented and not in the lineage. A model change upstream can break it silently. A persisted one is a second pipeline, with a warehouse cost no dbt build report shows.

Review the transformation logic living in Looker derived tables. Move the query into a dbt model and point the view at it. If it is only an aggregate of the model, rewrite it as a native derived table with explore_source.

Before:

view: customer_order_counts {
  derived_table: {
    sql: select customer_id, count(*) as order_count
         from analytics.fct_orders group by 1 ;;
  }
}

After:

view: customer_order_counts {
  derived_table: {
    explore_source: orders {
      column: customer_id { field: orders.customer_id }
      column: order_count { field: orders.count }
    }
  }
}

A SQL derived table is legitimate LookML and sometimes the right call. Examples include a short-lived analysis, or logic that depends on a user's filter at query time. For that reason it does not count towards the score. Name an owner and tell us, and it drops.

The .lkml files alone. The reader drops the derived table's SQL before any check runs, so the finding names the view and its line only.