ワンクリックで
lookml-sets
Guide to using LookML sets for grouping fields, controlling visibility, and managing drill paths.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
メニュー
Guide to using LookML sets for grouping fields, controlling visibility, and managing drill paths.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Looker Developer Onboarding: Step 3. Authenticates the Looker CLI using OAuth. Only execute this after Step 2 (CLI Verification using `installing-looker-cli`).
Looker Developer Onboarding: Step 4. Creates a database connection in Looker to Google BigQuery. Only execute this after Step 3 (CLI Authentication using `authenticating-looker-cli`).
Looker Developer Onboarding: Step 7 (Final Step). Creates a LookML dashboard in the project, imports it as a user-defined dashboard (UDD) in Looker, and iteratively refines it based on user feedback by syncing changes. Only execute this after Step 6 (Model Setup using `creating-lookml-model`).
Looker Developer Onboarding: Step 6. Creates LookML views and models based on the user's goals, maps model connections, validates LookML, and runs verification queries. Only execute this after Step 5 (Project Setup using `setting-up-looker-project`).
Looker Developer Onboarding: Step 1. Guides the agent to explore BigQuery data and define the onboarding goal. This is the first active step, to be executed immediately after reading the parent orchestrator `looker-developer-onboarding`.
Looker Developer Onboarding: Step 2. Verifies that the Looker CLI is available in the PATH, or installs it from GitHub Releases if missing. Only execute this after Step 1 (Data Discovery using `exploring-data-for-looker`).
| name | lookml-sets |
| description | Guide to using LookML sets for grouping fields, controlling visibility, and managing drill paths. |
| license | Apache-2.0 |
| metadata | {"publisher":"google","version":"v1"} |
Sets are reusable lists of fields (dimensions, measures, and filters) defined within a view or a model. They are primarily used to group fields together for various purposes such as drill-down paths, explore field visibility, and more.
set: set_name {
fields: [field_name1, field_name2, view_name.field_name3, ...]
}
[set_name*] includes all fields from another set.[-field_name] excludes a specific field.view_name.set_name* refers to a set in another view (ensure views are joined).Sets are the standard way to define what happens when a user clicks on a measure value. Instead of listing fields repeatedly, define a set and reference it.
view: orders {
# ... dimensions ...
set: order_details {
fields: [id, created_date, status, user.email]
}
measure: count {
type: count
drill_fields: [order_details*]
}
}
You can use sets at the Explore level to explicitly define which fields are visible to users. This is best practice for curating Explores.
explore: orders {
fields: [ALL_FIELDS*] # Start with everything (default)
# OR
fields: [orders.order_details*, users.user_info*] # Allowlist specific sets
}
Use sets to exclude specific fields from an Explore without hiding them at the view level (which hides them globally).
explore: orders {
fields: [ALL_FIELDS*, -users.password_hash]
}
detail SetEvery view should ideally have a default set (commonly named detail or drill_set) that includes the most relevant fields for drilling into a record from that view.
view: users {
dimension: id { primary_key: yes ... }
dimension: name { ... }
dimension: email { ... }
# Standard set for drilling
set: detail {
fields: [id, name, email]
}
}
snake_case for set names.user_info, financial_metrics, drill_detail.While you can reference other_view.field in a view's set, this creates a dependency. Ensure that other_view is always joined whenever the set is used.
fields: [orders.detail*, users.detail*]).You can build sets on top of other sets.
set: basic_info {
fields: [id, name]
}
set: extended_info {
fields: [basic_info*, email, created_date]
}