Validador de estilo de integración continua

El validador de estilo de integración continua (CI) aplica los estándares de codificación, las convenciones de nomenclatura y las prácticas recomendadas estructurales de LookML en todo tu proyecto de LookML con el verificador de estilo de LookML. Al verificar tus archivos LookML con un conjunto configurable de reglas de estilo, el Validador de estilo ayuda a tu equipo a mantener una base de código limpia, coherente y legible.

Para ejecutar el Validador de estilo, debes agregar un archivo de configuración llamado lkmlstyle.yaml (o lkmlstyle.yml) al directorio raíz del repositorio de tu proyecto de LookML. Consulta la sección Archivo de configuración de esta página para obtener detalles sobre cómo configurar el verificador de estilo.

Para obtener información sobre cómo configurar y ejecutar el validador de estilo en un paquete de CI, y ver el resultado de la validación, consulta las páginas de documentación Cómo crear un paquete de integración continua, Cómo ejecutar paquetes de integración continua y Cómo ver los resultados de una ejecución de CI.

Antes de comenzar

Para usar el validador de diseño en la integración continua, necesitas lo siguiente:

Archivo de configuración

Se requiere un archivo de configuración para ejecutar el Validador de estilo en Looker CI. Cuando se ejecuta el Validador de estilo, se verifica automáticamente el directorio raíz del repositorio de tu proyecto de LookML en busca de un archivo de configuración en el siguiente orden de prioridad:

  1. lkmlstyle.yaml
  2. lkmlstyle.yml

Si ambos archivos existen en el directorio raíz, lkmlstyle.yaml tiene prioridad y se ignora lkmlstyle.yml.

Si no se encuentra lkmlstyle.yaml ni lkmlstyle.yml en el directorio raíz del proyecto (y no se pasa ninguna configuración personalizada a través de la API), la ejecución de la validación de estilo falla con el error "No style validator configuration provided".

Para ejecutar las 25 reglas integradas estándar con su configuración predeterminada, puedes usar la siguiente información de configuración mínima en tu archivo lkmlstyle.yaml:

schema_version: 1
ruleset_version: "all-v1.0"

De lo contrario, puedes personalizar tu archivo de configuración. El archivo de configuración puede contener los siguientes parámetros de nivel superior:

Parámetro Tipo ¿Es obligatorio? Predeterminado Descripción
schema_version Número entero Sí Ninguno Es la versión del esquema de configuración. La versión 1 es la única compatible y se debe especificar de forma explícita.
ruleset_version String Sí Ninguno Es la edición del conjunto de reglas de referencia que se heredará. Valores admitidos: "all-v1.0", "none".
ignore_files Lista de strings No [] Son los patrones glob de los archivos que se excluirán por completo de la validación de estilo.
rules Mapa No {} Personalizaciones globales (severity y version) para reglas individuales. También puedes habilitar reglas integradas que no se incluyen en el conjunto de reglas de referencia y cambiar la gravedad de las reglas personalizadas. Consulta la sección Personalizaciones de reglas para ver ejemplos.
overrides Lista de mapas No [] Son anulaciones de reglas con alcance que ajustan o habilitan las gravedades para rutas de acceso a archivos coincidentes específicos.
custom_rules Lista de mapas No [] Reglas personalizadas declarativas definidas por el usuario

ruleset_version

El parámetro ruleset_version define la base de tu estrategia de validación de estilo:

  • "all-v1.0" (Recomendado): Activa las 25 reglas de estilo de LookML integradas estándares en el nivel de gravedad error. Esta opción es ideal para los equipos que desean aplicar la calidad de forma integral de inmediato.
  • "none": Comienza con cero reglas integradas habilitadas. Esta opción es ideal para los equipos que desean adoptar la validación de estilo de forma incremental, habilitar reglas específicas una por una o ejecutar solo reglas organizativas personalizadas. Para habilitar una regla integrada cuando ruleset_version es "none", asígnale a la regla una gravedad warn o error en el bloque rules o en un bloque overrides.

ignore_files

El parámetro ignore_files acepta una lista de patrones glob para los archivos que deseas omitir por completo durante la validación de estilo. No se inspeccionan los archivos que coinciden con estos patrones para detectar reglas integradas o personalizadas.

La sintaxis de comodín admitida incluye lo siguiente:

  • *: Coincide con cualquier secuencia de caracteres que no sean separadores dentro de un solo nivel de directorio.
  • **: Coincide con cualquier secuencia de caracteres en varios niveles de directorio anidados.
  • ?: Coincide con cualquier carácter único.
  • {a,b} y [abc]: Coinciden con alternativas y clases de caracteres (sintaxis de glob de Java).

Las siguientes reglas de coincidencia de rutas de acceso se aplican a todos los patrones glob del archivo de configuración, incluidos los ignore_files de nivel superior, así como los files y ignore_files en overrides:

  • Las rutas de acceso son relativas al directorio raíz del proyecto. Se ignora un ./ o / inicial.
  • Un patrón sin una barra (/) coincide con cualquier profundidad de directorio. Por ejemplo, *.ignore.lkml coincide con x.ignore.lkml y views/x.ignore.lkml.
  • Un patrón que termina en / coincide con todo lo que se encuentra en ese directorio.
  • Un patrón que termina en .lkml o .lookml también coincide con las extensiones compuestas. Por ejemplo, *.ignore.lkml coincide con x.ignore.view.lkml.

En el siguiente ejemplo, se excluyen los archivos de proveedores, los archivos de LookML heredados y los paneles de LookML:

ignore_files:
  - "vendor/**"
  - "legacy/**/*.lkml"
  - "*.ignore.lkml"
  - "dashboards/*.dashboard.lookml"

rules

Puedes usar el bloque rules para ajustar la gravedad del diagnóstico de reglas individuales en todo tu proyecto:

rules:
  boolean-dimension-name-prefix:
    severity: warn
  view-dimension-order:
    severity: disabled
  numeric-measure-value-format-presence:
    severity: error

Cualquier regla integrada que se enumere en rules (o en un bloque overrides) con una gravedad de warn o error está activa, incluso cuando ruleset_version se establece en "none". Por ejemplo, la siguiente configuración inicial comienza con ruleset_version: "none" y habilita solo dos reglas integradas:

schema_version: 1
ruleset_version: "none"

rules:
  join-relationship-presence:
    severity: error
  explore-label-presence:
    severity: warn

También puedes usar el bloque rules para cambiar la gravedad de una regla personalizada haciendo referencia a su nombre.

severity

Cada regla se puede configurar con uno de los siguientes niveles de gravedad que no distinguen entre mayúsculas y minúsculas:

  • error: Se trata como incumplimiento grave. Los errores hacen que falle la ejecución de CI.
  • warn: Se emite como una advertencia no bloqueante. Las advertencias aparecen en los informes de ejecución de la CI, pero no hacen que falle la ejecución de la CI.
  • disabled: Desactiva la regla por completo y la omite durante la validación.
Se validan los nombres de las reglas en los bloques overrides.

overrides

Puedes usar el parámetro overrides para modificar la gravedad de las reglas en archivos o directorios específicos sin cambiar la gravedad en el resto de tu proyecto de LookML. Por ejemplo, puedes usar overrides para relajar las reglas de las vistas de etapa de pruebas o los modelos heredados, ajustar las reglas de las rutas críticas o habilitar reglas específicas solo para ciertos directorios cuando ruleset_version es "none".

Cada entrada de la lista overrides admite los siguientes campos:

Campo Tipo ¿Es obligatorio? Descripción
files Lista de strings Sí Son los patrones glob que coinciden con los archivos a los que se aplica este bloque de anulación. No puede estar vacío.
ignore_files Lista de strings No Son los patrones glob que se excluirán de este bloque de anulación específico.
rules Mapa Sí Es un mapa de los nombres de las reglas y sus configuraciones de gravedad. No puede estar vacío. Solo se permite severity (y es obligatorio) en los bloques de anulación. Los nombres de las reglas deben ser nombres de reglas integradas o personalizadas válidos.

En el siguiente ejemplo, se inhabilitan las verificaciones de ordenamiento de dimensiones y se degradan los errores de descripción faltante a advertencias para los paneles y las vistas heredados:

overrides:
  - files:
      - "views/legacy/**"
      - "dashboards/*.dashboard.lookml"
    ignore_files:
      - "views/legacy/core_*.view.lkml"
    rules:
      view-dimension-order:
        severity: disabled
      visible-dimension-description-presence:
        severity: warn

custom_rules

Puedes definir reglas personalizadas declarativas en la sección custom_rules de tu archivo de configuración para aplicar convenciones de nomenclatura específicas de la organización, patrones arquitectónicos obligatorios y gobernanza estructural.

Todas las definiciones de reglas personalizadas admiten los siguientes parámetros comunes:

Campo Tipo ¿Es obligatorio? Descripción
name String Sí Identificador único, en formato de guiones por convención, como finance-measure-prefix. No debe coincidir con nombres de reglas integradas ni con otras reglas personalizadas.
title String Sí Es el mensaje legible por humanos que se informa cuando se produce un incumplimiento, con el formato (<rule-name>) <title>.
rule_type String Sí Arquetipo de la regla: pattern_match, property, order, first_child o unique. No distingue mayúsculas de minúsculas; se acepta pattern como alias de pattern_match.
severity String No Nivel de diagnóstico: error (predeterminado), warn o disabled. Se puede anular con rules y overrides.
rationale String No Documenta por qué existe la regla.
select Cadena o lista No Ruta del nodo del árbol de sintaxis abstracta (AST) hacia el destino, como "view.dimension", "explore" o ["dimension", "dimension_group"]. Si se omite, la regla se aplica a todos los nodos que coincidan con filters.
filters Mapa No Son los filtros de propiedad que deben coincidir en el nodo objetivo, como primary_key: true.
parent_filters Mapa No Son los filtros de propiedad que deben coincidir con el elemento superior inmediato del nodo objetivo.

Cada tipo de regla solo acepta sus propias claves específicas del tipo. Las claves desconocidas o las que pertenecen a un tipo de regla diferente (como order_by en una regla pattern_match) generan un error de configuración.

select

El parámetro select determina qué elementos de LookML evalúa la regla personalizada:

  • Elemento directo: Segmenta por un tipo de elemento LookML específico, como select: "dimension", select: "measure", select: "view", select: "explore", select: "join", select: "model" o select: "include".
  • Ruta anidada de elemento principal y secundario: Segmenta los elementos definidos dentro de un elemento principal inmediato específico, como select: "view.dimension" (dimensiones definidas dentro de las vistas) o select: "explore.join" (uniones definidas dentro de las Exploraciones). El elemento superior debe ser el inmediato, y solo se usan los dos últimos segmentos de una ruta de acceso (por lo que a.b.c se comporta como b.c).
  • Varios objetivos: Segmenta para varios tipos de elementos con una cadena separada por comas o una lista, como select: "dimension, dimension_group" o select: ["dimension", "dimension_group"].

Los nombres de los selectores, los filtros y los elementos secundarios son palabras clave de LookML exactas que distinguen mayúsculas de minúsculas. Un nombre mal escrito no se informa como un error de configuración, sino que la regla nunca coincide.

filters y parent_filters

Puedes usar filters y parent_filters para definir mejor los nodos segmentados en función de las propiedades de LookML que se declaran de forma explícita en el archivo de LookML.

type: "string"
  • Igualdad booleana: Coincide con las propiedades booleanas declaradas de forma explícita, como primary_key: true o hidden: true.
  • Igualdad de cadenas: Coincide con valores de cadena exactos, como type: "yesno" o type: "count".
  • Lista de uno de: Coincide con cualquier valor de una lista, como type: ["string", "number", "date"].
  • Verificación de presencia: Verifica si hay un bloque o una propiedad pasando una cadena vacía, como derived_table: "".
  • Negación: Agrega el prefijo ! a la clave o al valor para negar el filtro. Una clave negada debe estar entre comillas porque un ! inicial sin comillas es sintaxis de etiqueta YAML y hace que no se pueda analizar el archivo de configuración:
    • "!hidden": true o hidden: "!true" coinciden con los elementos visibles (no ocultos), incluidos los campos que no declaran hidden.
    • type: ["!yesno", "!date"] coincide con los tipos que no son yesno ni date.

rule_type

Cada regla personalizada debe especificar uno de los siguientes cinco arquetipos de reglas para el parámetro rule_type:

pattern_match

Aplica patrones de expresiones regulares a los nombres de entidades o valores de propiedades de LookML. Debes especificar exactamente uno de match o should_not_match (si se configuran ambos, solo se aplica match y se ignora should_not_match de forma silenciosa):

  • match (cadena, expresión regular): Es el patrón con el que debe coincidir el destino.
  • should_not_match (cadena, expresión regular): Es el patrón con el que no debe coincidir el destino.

Los patrones son expresiones regulares de Java que se validan cuando se carga el archivo de configuración. La coincidencia es no anclada (una coincidencia de subcadena); por ejemplo, match: "fin_" pasa para my_fin_total. Usa ^ y $ para que coincida con todo el valor.

Si select segmenta una propiedad en lugar de una entidad (por ejemplo, select: "measure.sql" o select: "dimension.label"), la expresión regular se evalúa en función del valor de la propiedad en lugar del nombre de la entidad. Las reglas integradas measure-sql-table-reference y dimension-label-redundant-yes-no funcionan de esta manera.

Ejemplo que exige que las medidas de moneda terminen con _usd o _eur:

- name: currency-measure-suffix
  title: "Currency measures must end with a currency code like _usd or _eur"
  rule_type: pattern_match
  severity: error
  select: "view.measure"
  filters:
    value_format_name: ["usd", "usd_0", "eur", "eur_0"]
  match: "^.*_(usd|eur)$"

Ejemplo que prohíbe las dimensiones temporales o de borrador:

- name: forbid-temporary-dimensions
  title: "Dimensions must not start with 'tmp_' or 'test_'"
  rule_type: pattern_match
  severity: error
  select: "dimension"
  should_not_match: "^(tmp|test)_.*"
property

Exige la presencia o prohibición obligatoria de propiedades secundarias específicas dentro de los objetos de LookML. Debes especificar exactamente uno de requires_child o forbidden_child (si se configuran ambos, solo se aplica requires_child y se ignora forbidden_child de forma silenciosa):

  • requires_child (cadena o lista): Nombre o nombres de las propiedades secundarias que deben estar presentes. Cuando especificas una lista, la regla se cumple si está presente cualquiera de los elementos secundarios que se indican en la lista.
  • forbidden_child (cadena o lista): Nombre o nombres de propiedades secundarias que no deben estar presentes. Cuando especificas una lista, el nodo se marca si está presente cualquier elemento secundario de la lista.
  • child_filters (Mapa, opcional): Son filtros de propiedad adicionales que debe satisfacer el elemento secundario obligatorio.

Ejemplo que requiere descripciones en todas las dimensiones visibles:

- name: require-visible-dimension-description
  title: "Visible dimensions must specify a description"
  rule_type: property
  severity: warn
  select: "view.dimension"
  filters:
    "!hidden": true
  requires_child: "description"

Ejemplo que prohíbe sql_table_name en tablas derivadas:

- name: forbid-sql-table-name-on-derived-views
  title: "Derived table views cannot specify sql_table_name"
  rule_type: property
  severity: error
  select: "view"
  filters:
    derived_table: ""
  forbidden_child: "sql_table_name"
order

Aplica el orden alfabético de los elementos secundarios dentro de un contenedor.

  • order_by (cadena, obligatorio): Es el tipo de LookML de los elementos secundarios hermanos que se deben ordenar, por lo general, "dimension" o "measure". Solo se comparan los elementos secundarios directos del nodo seleccionado, y los elementos secundarios de dimension_group no se incluyen en "dimension".

Los nombres se comparan de forma que distingue mayúsculas de minúsculas por código de carácter: las letras mayúsculas se ordenan antes que las letras minúsculas, y _ se ordena entre ellas.

Ejemplo que requiere que las dimensiones se enumeren en orden alfabético dentro de las vistas:

- name: custom-alphabetical-dimensions
  title: "Dimensions must be kept in alphabetical order within views"
  rule_type: order
  severity: error
  select: "view"
  order_by: "dimension"
first_child

Exige que un elemento que coincida con un filtro específico aparezca como el primer elemento secundario de su categoría.

  • position (cadena, opcional): Es la restricción de posición. Debe ser "first" (el valor predeterminado es "first").

Para las reglas de first_child, select debe usar el formulario parent.child_type, como "view.dimension". El parámetro filters identifica al hijo que debe aparecer primero; no reduce los nodos principales que se verifican. El esquema acepta el parámetro parent_filters, pero se ignora para este tipo de regla.

Ejemplo que requiere que la dimensión de clave primaria se declare primero en una vista:

- name: custom-primary-key-first-dimension
  title: "Primary key dimension must be the first dimension in the view"
  rule_type: first_child
  severity: error
  select: "view.dimension"
  filters:
    primary_key: true
  position: first
unique

Exige la unicidad de un valor de propiedad en todos los nodos coincidentes de los archivos validados durante una ejecución de CI.

  • unique_property (cadena, obligatorio): Es el nombre de la propiedad que debe tener valores únicos en todos los nodos coincidentes, como "sql_table_name" o "label".

Los valores se comparan como cadenas exactas, y se registran tanto la primera ocurrencia como cada duplicado. Si una ejecución de validación solo verifica un subconjunto de los archivos del proyecto, no se detectarán los duplicados en los archivos fuera de ese subconjunto.

Ejemplo que garantiza nombres de tablas únicos en todas las vistas:

- name: custom-sql-table-name-uniqueness
  title: "Each view must reference a unique sql_table_name"
  rule_type: unique
  severity: error
  select: "view"
  unique_property: "sql_table_name"

Restricciones de reglas personalizadas

Cuando crees reglas personalizadas, cumple con las siguientes restricciones:

  1. Sin colisión con nombres de reglas integradas: Las reglas personalizadas no pueden reutilizar ningún nombre del catálogo de reglas integradas, como boolean-dimension-name-prefix o sql-table-name-uniqueness.
  2. Nombres personalizados únicos: Cada regla personalizada debe tener un nombre distinto en la lista custom_rules.
  3. Formato de guiones: Los nombres de las reglas deben usar el formato de guiones (lowercase-words-with-hyphens).

Orden de evaluación de la configuración

Cuando el Validador de estilo evalúa un archivo LookML, las reglas de configuración se aplican en el siguiente orden:

  1. Exclusión de archivos: Si el archivo coincide con algún patrón en ignore_files, se omite por completo.
  2. Reglas activas: Las reglas activas para el archivo constan de las reglas de ruleset_version (all-v1.0 o none), además de cualquier regla integrada a la que se le asigne una gravedad warn o error en rules o en un bloque overrides coincidente, además de todas las reglas definidas en custom_rules.
  3. Resolución de gravedad: Para cada regla activa, tiene prioridad el primer parámetro de configuración de los siguientes que especifica una gravedad: el último bloque overrides coincidente, luego el bloque rules global, luego el propio severity de la regla personalizada y, por último, la gravedad predeterminada (error).
  4. Reglas inhabilitadas: Las reglas cuya gravedad resuelta es disabled se omiten para ese archivo.

Archivo de configuración de ejemplo

En el siguiente ejemplo, se muestra un archivo lkmlstyle.yaml completo que demuestra la selección del conjunto de reglas de referencia, las exclusiones de archivos, las personalizaciones de reglas globales, las anulaciones con alcance y las reglas personalizadas:

# Schema version
schema_version: 1

# Baseline ruleset edition (all-v1.0 or none)
ruleset_version: "all-v1.0"

# Files completely ignored by the style validator
ignore_files:
  - "vendor/**"
  - "*.ignore.lkml"
  - "legacy_dashboards/*.dashboard.lookml"

# Built-in rule customizations
rules:
  view-dimension-order:
    severity: warn
  numeric-measure-value-format-presence:
    severity: warn
  sql-table-name-uniqueness:
    severity: error
  # Replaced by the custom first_child rule below
  primary-key-first-dimension:
    severity: disabled

# Directory/file scoped overrides
overrides:
  - files:
      - "views/staging/**"
    rules:
      visible-dimension-description-presence:
        severity: disabled
      primary-key-visibility:
        severity: warn

# Custom rules catalog
custom_rules:
  # 1. Pattern Match: Finance dimensions must start with fin_
  - name: finance-dimension-prefix
    title: "Finance dimensions must be prefixed with fin_"
    rule_type: pattern_match
    severity: error
    rationale: "Ensures clarity in the field picker for finance metrics."
    select: "view.dimension"
    filters:
      view_label: "Finance"
    match: "^fin_[a-z0-9_]+$"

  # 2. Pattern Match: Forbid draft or test views
  - name: forbid-draft-views
    title: "Views cannot be named with draft_ or test_ prefixes"
    rule_type: pattern_match
    severity: error
    select: "view"
    should_not_match: "^(draft|test)_.*"

  # 3. Property: Require explicit relationship on joins
  - name: require-join-relationship
    title: "All joins must declare an explicit relationship"
    rule_type: property
    severity: error
    select: "explore.join"
    requires_child: "relationship"

  # 4. Property: Explores must not use sql_always_where
  - name: forbid-sql-always-where
    title: "Explores should use always_filter instead of sql_always_where"
    rule_type: property
    severity: warn
    select: "explore"
    forbidden_child: "sql_always_where"

  # 5. Order: Dimension groups inside views must be alphabetical
  - name: view-dimension-groups-alphabetical
    title: "Dimension groups must appear in alphabetical order within views"
    rule_type: order
    severity: warn
    select: "view"
    order_by: "dimension_group"

  # 6. First Child: Primary key must be the first dimension
  - name: custom-primary-key-first-dimension
    title: "The primary key must be defined as the first dimension in the view"
    rule_type: first_child
    severity: error
    select: "view.dimension"
    filters:
      primary_key: true
    position: first

  # 7. Unique: Views must not share the same label
  - name: unique-view-labels
    title: "Views must have unique labels"
    rule_type: unique
    severity: warn
    select: "view"
    unique_property: "label"

Alcance y resultados de la validación

En las siguientes secciones, se describen los archivos que verifica el Validador de diseño y cómo se informan los resultados de la validación:

Archivos validados

  • Solo se validan los archivos .lkml y .lookml en el proyecto raíz. No se validan los proyectos de dependencia importados (locales o remotos).
  • Cada archivo se valida según su propio contenido. No se siguen las instrucciones de include:, y los objetos extraídos a través de una instrucción de include: no se validan como parte del archivo que los incluye.
  • Las ejecuciones de CI que activan los trabajos de CI de dbt Cloud validan la rama de LookML de producción en lugar de una rama de desarrollo.

Comportamiento y salida de aprobación o reprobación

  • La ejecución de un validador de diseño solo falla si al menos un diagnóstico tiene la gravedad error. Las advertencias por sí solas no hacen que falle la ejecución.
  • En la página de resultados de la ejecución de CI, cada resultado de diagnóstico incluye el nombre de la regla, la ruta de acceso, el número de línea, un fragmento de contexto y un vínculo a la documentación de la regla. Para obtener más información sobre cómo ejecutar conjuntos de pruebas y ver los resultados, consulta Cómo ejecutar conjuntos de pruebas de integración continua y Cómo ver los resultados de una ejecución de CI.
  • Un archivo de configuración no válido produce un solo error invalid-config en el archivo de configuración en la línea 1, y la ejecución de la validación falla.

Validación incremental

Puedes habilitar la validación incremental para el validador de estilo seleccionando la casilla de verificación Solo errores incrementales (habilitada de forma predeterminada) en la sección Validador de estilo cuando creas o editas un conjunto de pruebas de integración continua.

Cuando se habilita la validación incremental, el Validador de diseño solo informa los incumplimientos nuevos en tu rama de desarrollo:

  1. Valida la rama de desarrollo.
  2. Valida la rama de destino con el archivo de configuración de la rama de desarrollo.
  3. Solo informa los incumplimientos que aún no están presentes en la rama de destino.

Ten en cuenta el siguiente comportamiento cuando se habilita la validación incremental:

  • Los incumplimientos preexistentes en la rama de destino no hacen que falle la ejecución.
  • Dado que el archivo de configuración de la rama de desarrollo se usa para validar ambas ramas, un cambio de configuración en la rama de desarrollo no puede ocultar incumplimientos preexistentes ni hacer que el LookML preexistente aparezca como incumplimientos nuevos por sí solo.
  • La rama de desarrollo debe contener un archivo de configuración lkmlstyle.yaml (o lkmlstyle.yml); de lo contrario, la ejecución fallará con un error de falta de configuración.

Cuando la opción Solo errores incrementales está inhabilitada, se informa cada incumplimiento que se encuentra en la rama validada.

Catálogo de reglas integradas

En la siguiente tabla, se enumeran las 25 reglas integradas estándar disponibles en el conjunto de reglas all-v1.0:

Nombre de la regla Entidad objetivo Resumen de la regla
average-measure-name-prefix Medir Las medidas con type: average o average_distinct deben comenzar con avg_ o average_.
boolean-dimension-name-prefix Dimensión Las dimensiones de tipo sí/no deben comenzar con is_, has_ o does_.
count-measure-name-prefix Medir Las medidas con type: count o count_distinct deben comenzar con count_.
dimension-group-name-suffix Grupo de dimensiones Los grupos de dimensiones no deben terminar con _at, _date ni _time.
dimension-label-redundant-yes-no Dimensión Las etiquetas de dimensión de sí/no no deben incluir un marcador de sí/no, como (Yes / No) o (yes/no) (sin importar el uso de mayúsculas o espacios).
dimension-name-snake-case Dimensión Los nombres de las dimensiones y los grupos de dimensiones deben estar en minúsculas snake_case.
explore-fields-presence Explorar Los Explorar deben definir la propiedad fields:.
explore-label-presence Explorar Los Explorar deben definir una propiedad label: explícita.
includes-wildcard-usage Incluir Las instrucciones include: no deben usar comodines para los archivos de vista (como *.view.lkml o /views/*.view). No se marcan otros comodines.
join-relationship-presence Unirse Las declaraciones de Explore join: deben especificar un relationship:.
measure-name-snake-case Medir Los nombres de las métricas deben estar en minúsculas snake_case.
measure-sql-table-reference Medir Las medidas deben hacer referencia a las dimensiones con ${dimension_name}, no con ${TABLE}.column.
numeric-measure-value-format-presence Medir Las medidas con type: count, sum, average o number deben especificar value_format: o value_format_name:.
pdt-view-name-prefix Ver Las tablas derivadas persistentes (PDT) deben comenzar con pdt_. Una vista se considera PDT si su derived_table establece datagroup_trigger, sql_trigger_value, interval_trigger o persist_for, o bien establece materialized_view: yes.
primary-key-first-dimension Dimensión La dimensión de clave primaria debe ser la primera dimensión definida en la vista.
primary-key-visibility Dimensión Las dimensiones de clave primaria deben estar ocultas (hidden: yes).
sql-table-name-uniqueness Ver Varias vistas no deben apuntar al mismo sql_table_name.
sum-measure-name-prefix Medir Las medidas con type: sum o sum_distinct deben comenzar con sum_ o total_.
view-dimension-order Ver Las dimensiones dentro de una vista deben organizarse en orden alfabético.
view-label-presence Ver Las vistas deben definir un label: explícito.
view-measure-order Ver Las medidas dentro de una vista deben organizarse en orden alfabético.
view-name-snake-case Ver Los nombres de las vistas deben estar en minúsculas snake_case (se permite un + inicial para los refinamientos).
view-primary-key-presence Ver Las vistas con sql_table_name o derived_table (y sin extends) deben definir una clave primaria.
visible-dimension-description-presence Dimensión Las dimensiones visibles deben tener un description:.
visible-measure-description-presence Medir Las medidas visibles deben tener un description:.

Soluciona problemas

En las siguientes secciones, se describen los problemas de configuración comunes y las variaciones de sintaxis admitidas cuando se soluciona un problema del Validador de diseño:

Errores de configuración

Los siguientes problemas se rechazan cuando se carga el archivo de configuración y se informan como un error de invalid-config:

  • Claves de nivel superior desconocidas o claves desconocidas dentro de la configuración de una regla.
  • Falta schema_version o ruleset_version, o bien se usó un valor no admitido para cualquiera de los parámetros.
  • Son abreviaturas de la gravedad escalar, como rule-name: warn.
  • Un bloque de anulación con files o rules faltantes o vacíos, o una configuración de regla dentro de un bloque de anulación sin severity.
  • Es un nombre de regla desconocido en un bloque de anulación.
  • Una regla personalizada cuyo nombre duplica otra regla personalizada o una regla integrada.
  • Una clave específica del tipo que se usa en el rule_type incorrecto (por ejemplo, order_by en una regla de pattern_match)
  • Una expresión regular no válida.
  • Falta un parámetro order_by (para reglas de order) o un parámetro unique_property (para reglas de unique).
  • Un valor de position que no sea first (para las reglas de first_child)
  • Un ! inicial sin comillas en una clave de filtro, como !hidden: true, que es una sintaxis de etiqueta YAML no válida y hace que no se pueda analizar el archivo de configuración.

Problemas de configuración silenciosos

  • Los nombres de reglas con errores ortográficos en el bloque rules global se ignoran de forma silenciosa.
  • Los nombres de tipos de LookML mal escritos en select, filters, parent_filters, requires_child, forbidden_child o order_by no generan un error. En cambio, la regla nunca coincide (o, en el caso de requires_child, siempre falla).
  • Si especificas match y should_not_match, o bien requires_child y forbidden_child, solo se aplica el primer parámetro de cada par y se ignora el segundo.
  • Especificar parent_filters en una regla de first_child no tiene ningún efecto y se ignora.
  • Los filtros solo coinciden con las propiedades que se declaran de forma explícita en el archivo LookML, no con los valores predeterminados de LookML (consulta la sintaxis de filtrado).
  • Los patrones de expresiones regulares en las reglas pattern_match son coincidencias de subcadenas sin anclaje, a menos que las ancles con ^ y $ (consulta pattern_match).

Variaciones de sintaxis aceptadas

  • Los valores de severity y rule_type no distinguen mayúsculas de minúsculas.
  • Se acepta rule_type: pattern como alias para pattern_match.
  • Se ignoran los espacios en blanco iniciales y finales en ruleset_version.