원클릭으로
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]
}