mcpField
L
lookml-view

lookml-view

github.com/looker-open-sourceData & databases43151 installsUpdated 2w ago
Repository

About lookml-view

A skill that defines conventions for creating and maintaining LookML views. It covers file organization, primary keys, extensions, refinements, and choosing native derived tables where suitable.

Key features

  1. 01Defines view file naming and organization
  2. 02Requires explicit table names and primary keys
  3. 03Guides extensions and refinements
  4. 04Recommends native derived tables where suitable
  5. 05Sets naming and description conventions

Use cases

  1. 01Create a standard LookML view
  2. 02Layer changes onto an existing view
  3. 03Reuse logic across views
  4. 04Choose a derived-table approach

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/looker-open-source/looker-skills --skill lookml-view

After installing, type/lookml-viewin Claude Code to confirm it loaded.

Bundled filesreferences/derived_table.md

Details

From the project README

Instructions

1. File Organization

  • Standard Views: views/[datasource_name]/[view_name].view.lkml
  • Extended Views: views/[datasource_name]/[view_name]_ext.view.lkml
  • Refinements: views/[datasource_name]/[view_name]_rfn.view.lkml
  • NDTs: views/[datasource_name]/[view_name]_ndt.view.lkml
  • SDTs: views/[datasource_name]/[view_name]_sdt.view.lkml

2. Core Standards

  1. sql_table_name: Required for standard views. Defaults are fragile; be explicit.
  2. Primary Key:
    • Convention: place the primary key as the first dimension for readability.
    • Must have primary_key: yes — Why: essential for symmetric aggregates, which Looker uses to handle JOIN row duplication correctly (prevents fanout in multi-join queries).
  3. Refinements: Use + before the view name (e.g., view: +users) to refine existing views without modifying the original file.
  4. Extensions: Use extends to reuse logic from other views.
  5. Derived Tables: Evaluate and nudge towards Native Derived Tables (NDTs) (explore_source) over SQL Derived Tables (sql) where possible. When creating entity rollups or summary facts (e.g., user_order_facts), assess whether an existing Explore can source the data. NDTs are recommended because they minimize code drift and automatically inherit underlying LookML descriptions, formatting, and Row-Level Security (RLS). If an NDT is too complex, or if specific SQL features are required, an SDT is fully acceptable.

3. Best Practices

  • Naming: Use snake_case for view names and filenames.
  • Descriptions: Add descriptions to the view itself if it helps explain its purpose (e.g., "Daily active users aggregated by region").
  • Output Format: Ensure the file ends with a newline.

4. Related Skills

Examples

Basic View

view: users {
  sql_table_name: `project.dataset.users` ;;

  dimension: user_id {
    primary_key: yes
    type: number
    sql: ${TABLE}.id ;;
    group_label: "IDs"
    description: "Unique internal user ID."
  }

  dimension: email {
    type: string
    sql: ${TABLE}.email ;;
    description: "User's email address."
  }
}

Extended View

include: "/views/base/users.view"

view: users_extended {
  extends: [users]

  dimension: lifetime_value {
    type: number
    sql: ${TABLE}.ltv ;;
    description: "Total lifetime value of the user."
  }
}

Refinement (Layering)

include: "/views/users.view"

view: +users {
  label: "All Users (Refined)"
  
  dimension: email {
    # Adding a description to an existing field
    description: "Primary contact email."
  }
}

Reference Skills

  • Derived Tables: Standard (SDT) and Native (NDT) derived table patterns/materialization.

Comments

Markdown supported