Validador de estilo de integração contínua

O validador de estilo de integração contínua (CI) aplica padrões de programação do LookML, convenções de nomenclatura e práticas recomendadas estruturais em todo o projeto do LookML usando o linter de estilo do LookML. Ao verificar seus arquivos LookML em relação a um conjunto configurável de regras de estilo, o validador de estilo ajuda sua equipe a manter uma base de código limpa, consistente e legível.

Para executar o validador de estilo, adicione um arquivo de configuração chamado lkmlstyle.yaml (ou lkmlstyle.yml) ao diretório raiz do repositório do projeto do LookML. Consulte a seção Arquivo de configuração desta página para saber como configurar o linter de estilo.

Para informações sobre como configurar e executar o Style Validator em um pacote de CI e ver a saída da validação, consulte as páginas de documentação Criar um pacote de integração contínua, Executar pacotes de integração contínua e Ver os resultados de uma execução de CI.

Antes de começar

Para usar o Style Validator na integração contínua, você precisa do seguinte:

Arquivo de configuração

Um arquivo de configuração é necessário para executar o validador de estilo na CI do Looker. Quando o validador de estilo é executado, ele verifica automaticamente o diretório raiz do repositório do projeto do LookML em busca de um arquivo de configuração na seguinte ordem de prioridade:

  1. lkmlstyle.yaml
  2. lkmlstyle.yml

Se os dois arquivos existirem no diretório raiz, lkmlstyle.yaml terá precedência e lkmlstyle.yml será ignorado.

Se lkmlstyle.yaml e lkmlstyle.yml não forem encontrados no diretório raiz do projeto (e nenhuma configuração personalizada for transmitida pela API), a execução da validação de estilo vai falhar com o erro "No style validator configuration provided".

Para executar todas as 25 regras integradas padrão com as configurações padrão, use as seguintes informações de configuração mínima no arquivo lkmlstyle.yaml:

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

Caso contrário, personalize o arquivo de configuração. O arquivo de configuração pode conter os seguintes parâmetros de nível superior:

Parâmetro Tipo Obrigatório? Padrão Descrição
schema_version Inteiro Sim Nenhum Versão do esquema de configuração. A versão 1 é a única compatível e precisa ser especificada explicitamente.
ruleset_version String Sim Nenhum Edição do conjunto de regras de base a ser herdada. Valores aceitos: "all-v1.0", "none".
ignore_files Lista de strings Não [] Padrões glob de arquivos a serem excluídos completamente da validação de estilo.
rules Mapa Não {} Personalizações globais (severity e version) para regras individuais. Também é possível ativar regras integradas que o conjunto de regras de referência não inclui e mudar a gravidade das regras personalizadas. Consulte a seção Personalizações de regras para ver exemplos.
overrides Lista de mapas Não [] Substituições de regras com escopo que ajustam ou ativam gravidades para caminhos de arquivo correspondentes específicos.
custom_rules Lista de mapas Não [] Regras personalizadas declarativas definidas pelo usuário.

ruleset_version

O parâmetro ruleset_version define a base da sua estratégia de validação de estilo:

  • "all-v1.0" (recomendado): ativa todas as 25 regras de estilo padrão integradas do LookML no nível de gravidade error. Essa opção é ideal para equipes que querem uma aplicação abrangente da qualidade sem precisar fazer nada.
  • "none": começa com zero regras integradas ativadas. Essa opção é ideal para equipes que querem adotar a validação de estilo de forma incremental, ativar regras específicas uma por uma ou executar apenas regras organizacionais personalizadas. Para ativar uma regra integrada quando ruleset_version for "none", atribua à regra uma gravidade warn ou error no bloco rules ou em um bloco overrides.

ignore_files

O parâmetro ignore_files aceita uma lista de padrões glob para arquivos que você quer ignorar completamente durante a validação de estilo. Os arquivos que correspondem a esses padrões não são inspecionados para regras integradas ou personalizadas.

A sintaxe curinga compatível inclui o seguinte:

  • *: corresponde a qualquer sequência de caracteres não separadores em um único nível de diretório.
  • **: corresponde a qualquer sequência de caracteres em vários níveis de diretório aninhados.
  • ?: corresponde a qualquer caractere único.
  • {a,b} e [abc]: correspondem a alternativas e classes de caracteres (sintaxe glob do Java).

As seguintes regras de correspondência de caminho se aplicam a todos os padrões glob no arquivo de configuração, incluindo ignore_files de nível superior, files e ignore_files em overrides:

  • Os caminhos são relativos ao diretório raiz do projeto. Um ./ ou / inicial é ignorado.
  • Um padrão sem uma barra (/) corresponde a qualquer profundidade de diretório. Por exemplo, *.ignore.lkml corresponde a x.ignore.lkml e views/x.ignore.lkml.
  • Um padrão que termina em / corresponde a tudo no diretório.
  • Um padrão que termina em .lkml ou .lookml também corresponde a extensões compostas. Por exemplo, *.ignore.lkml corresponde a x.ignore.view.lkml.

O exemplo a seguir exclui arquivos de fornecedores, arquivos legados do LookML e dashboards do LookML:

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

rules

Use o bloco rules para ajustar a gravidade do diagnóstico de regras individuais em todo o projeto:

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

Qualquer regra integrada listada em rules (ou em um bloco overrides) com uma gravidade de warn ou error fica ativa, mesmo quando ruleset_version está definido como "none". Por exemplo, a configuração inicial a seguir começa com ruleset_version: "none" e ativa apenas duas regras integradas:

schema_version: 1
ruleset_version: "none"

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

Também é possível usar o bloco rules para mudar a gravidade de uma regra personalizada referenciando o nome dela.

severity

Cada regra pode ser configurada com um dos seguintes níveis de gravidade, que não diferenciam maiúsculas de minúsculas:

  • error: tratada como uma violação fatal. Os erros causam falha na execução da CI.
  • warn: emitido como um aviso não bloqueador. Os avisos aparecem nos relatórios de execução da CI, mas não causam falha na execução.
  • disabled: desativa a regra completamente e a ignora durante a validação.

overrides

Você pode usar o parâmetro overrides para modificar as gravidades das regras em arquivos ou diretórios específicos sem mudar as gravidades no restante do projeto do LookML. Por exemplo, é possível usar overrides para flexibilizar regras de visualizações de teste ou modelos legados, restringir regras de caminhos críticos ou ativar regras específicas apenas para determinados diretórios quando ruleset_version for "none".

Cada entrada na lista overrides é compatível com os seguintes campos:

Campo Tipo Obrigatório? Descrição
files Lista de strings Sim Padrões glob que correspondem aos arquivos a que este bloco de substituição se aplica. Não pode ser vazio.
ignore_files Lista de strings Não Padrões glob a serem excluídos deste bloco de substituição específico.
rules Mapa Sim Mapa de nomes de regras para configurações de gravidade. Não pode ser vazio. Apenas severity é permitido (e obrigatório) em blocos de substituição. Os nomes de regras precisam ser válidos, sejam eles integrados ou personalizados.

O exemplo a seguir desativa as verificações de ordenação de dimensões e reduz os erros de descrição ausente para avisos em painéis e visualizações legados:

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

É possível definir regras personalizadas declarativas na seção custom_rules do arquivo de configuração para aplicar convenções de nomenclatura específicas da organização, padrões arquitetônicos obrigatórios e governança estrutural.

Todas as definições de regras personalizadas são compatíveis com os seguintes parâmetros comuns:

Campo Tipo Obrigatório? Descrição
name String Sim Identificador exclusivo, no formato dash-case por convenção, como finance-measure-prefix. Não pode entrar em conflito com nomes de regras integradas ou outras regras personalizadas.
title String Sim Mensagem legível por humanos informada quando ocorre uma violação, formatada como (<rule-name>) <title>.
rule_type String Sim O arquétipo da regra: pattern_match, property, order, first_child ou unique. Não diferencia maiúsculas de minúsculas. pattern é aceito como alias de pattern_match.
severity String Não Nível de diagnóstico: error (padrão), warn ou disabled. Pode ser substituído por rules e overrides.
rationale String Não Documenta por que a regra existe.
select String ou lista Não Caminho do nó da árvore de sintaxe abstrata (AST) para o destino, como "view.dimension", "explore" ou ["dimension", "dimension_group"]. Se omitida, a regra vai segmentar todos os nós que correspondem a filters.
filters Mapa Não Filtros de propriedade que precisam corresponder ao nó de destino, como primary_key: true.
parent_filters Mapa Não Filtros de propriedade que precisam corresponder ao elemento pai imediato do nó segmentado.

Cada tipo de regra aceita apenas chaves específicas do tipo. Chaves desconhecidas ou que pertencem a um tipo de regra diferente (como order_by em uma regra pattern_match) resultam em um erro de configuração.

select

O parâmetro select determina quais elementos da LookML a regra personalizada avalia:

  • Elemento direto: segmenta um tipo específico de elemento do LookML, como select: "dimension", select: "measure", select: "view", select: "explore", select: "join", select: "model" ou select: "include".
  • Caminho aninhado de pai-filho: segmenta elementos definidos em um pai imediato específico, como select: "view.dimension" (dimensões definidas em visualizações) ou select: "explore.join" (junções definidas em Análises). O elemento pai precisa ser o pai imediato, e apenas os dois últimos segmentos de um caminho são usados (assim, a.b.c se comporta como b.c).
  • Vários destinos: segmentar vários tipos de elementos usando uma string ou lista separada por vírgulas, como select: "dimension, dimension_group" ou select: ["dimension", "dimension_group"].

Os nomes de seletor, filtro e filho são palavras-chave exatas do LookML que diferenciam maiúsculas de minúsculas. Um nome com erro de ortografia não é informado como um erro de configuração. Em vez disso, a regra nunca corresponde.

filters e parent_filters

É possível usar filters e parent_filters para refinar os nós segmentados com base nas propriedades do LookML declaradas explicitamente no arquivo do LookML.

  • Igualdade booleana: corresponde a propriedades booleanas declaradas explicitamente, como primary_key: true ou hidden: true.
  • Igualdade de strings: corresponde a valores de string exatos, como type: "yesno" ou type: "count".
  • Lista de um de: corresponde a qualquer valor em uma lista, como type: ["string", "number", "date"].
  • Verificação de presença: confira se um bloco ou uma propriedade está presente transmitindo uma string vazia, como derived_table: "".
  • Negação: coloque o prefixo ! na chave ou no valor para negar o filtro. Uma chave negada precisa estar entre aspas porque um ! inicial sem aspas é uma sintaxe de tag YAML e faz com que o arquivo de configuração não seja analisado:
    • "!hidden": true ou hidden: "!true" correspondem a itens visíveis (não ocultos), incluindo campos que não declaram hidden.
    • type: ["!yesno", "!date"] corresponde a tipos que não são yesno nem date.

rule_type

Cada regra personalizada precisa especificar um dos cinco arquétipos de regra a seguir para o parâmetro rule_type:

pattern_match

Impõe padrões de expressão regular em nomes de entidades ou valores de propriedades da LookML. É necessário especificar exatamente um de match ou should_not_match. Se ambos forem definidos, apenas match será aplicado, e should_not_match será ignorado silenciosamente.

  • match (string, expressão regular): padrão que o destino precisa corresponder.
  • should_not_match (string, expressão regular): padrão que o destino não pode corresponder.

Os padrões são expressões regulares Java validadas quando o arquivo de configuração é carregado. A correspondência é não ancorada (uma correspondência de substring). Por exemplo, match: "fin_" é aprovado para my_fin_total. Use ^ e $ para corresponder ao valor inteiro.

Se select segmentar uma propriedade em vez de uma entidade (por exemplo, select: "measure.sql" ou select: "dimension.label"), a expressão regular será avaliada em relação ao valor da propriedade, e não ao nome de uma entidade. As regras integradas measure-sql-table-reference e dimension-label-redundant-yes-no funcionam dessa forma.

Exemplo que exige que as medidas de moeda terminem com _usd ou _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)$"

Exemplo que proíbe dimensões temporárias ou de rascunho:

- 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

Impõe a presença ou proibição obrigatória de propriedades filhas específicas em objetos do LookML. É necessário especificar exatamente um de requires_child ou forbidden_child. Se ambos forem definidos, apenas requires_child será aplicado, e forbidden_child será ignorado silenciosamente.

  • requires_child (string ou lista): nome ou nomes de propriedades secundárias que precisam estar presentes. Quando você especifica uma lista, a regra é atendida se qualquer um dos filhos listados estiver presente.
  • forbidden_child (string ou lista): nome ou nomes de propriedades filhas que não podem estar presentes. Quando você especifica uma lista, o nó é sinalizado se qualquer filho listado estiver presente.
  • child_filters (Mapa, opcional): outros filtros de propriedade que a criança obrigatória precisa atender.

Exemplo que exige descrições em todas as dimensões visíveis:

- 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"

Exemplo que proíbe sql_table_name em tabelas 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

Impõe a ordenação alfabética de elementos irmãos em um contêiner.

  • order_by (string, obrigatório): tipo LookML dos filhos irmãos a serem ordenados, geralmente "dimension" ou "measure". Apenas os filhos diretos do nó selecionado são comparados, e os filhos de dimension_group não são incluídos em "dimension".

Os nomes são comparados de acordo com o código de caracteres, que diferencia maiúsculas de minúsculas: letras maiúsculas são classificadas antes de letras minúsculas, e _ é classificado entre elas.

Exemplo que exige que as dimensões sejam listadas em ordem alfabética nas visualizações:

- 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

Força que um elemento que corresponda a um filtro específico apareça como o primeiro filho da categoria.

  • position (string, opcional): restrição de posição. Precisa ser "first" (o padrão é "first").

Para regras de first_child, select precisa usar o formato parent.child_type, como "view.dimension". O parâmetro filters identifica o filho que precisa aparecer primeiro, mas não restringe quais nós principais são verificados. O parâmetro parent_filters é aceito pelo esquema, mas é ignorado para esse tipo de regra.

Exemplo que exige que a dimensão da chave primária seja declarada primeiro em uma visualização:

- 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

Impõe a exclusividade de um valor de propriedade em todos os nós correspondentes nos arquivos validados durante uma execução de CI.

  • unique_property (string, obrigatório): nome da propriedade que precisa ter valores exclusivos em todos os nós correspondentes, como "sql_table_name" ou "label".

Os valores são comparados como strings exatas, e a primeira ocorrência e todos os duplicados são informados. Se uma execução de validação verificar apenas um subconjunto dos arquivos do projeto, os duplicados em arquivos fora desse subconjunto não serão detectados.

Exemplo que garante nomes de tabela exclusivos em todas as visualizações:

- 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"

Restrições de regras personalizadas

Ao criar regras personalizadas, siga estas restrições:

  1. Sem conflito com nomes de regras integradas: as regras personalizadas não podem reutilizar nenhum nome do catálogo de regras integradas, como boolean-dimension-name-prefix ou sql-table-name-uniqueness.
  2. Nomes personalizados exclusivos: cada regra personalizada precisa ter um nome diferente na lista custom_rules.
  3. Formato de traço: os nomes de regras devem usar o formato de traço (lowercase-words-with-hyphens).

Ordem de avaliação da configuração

Quando o validador de estilo avalia um arquivo do LookML, as regras de configuração são aplicadas na seguinte ordem:

  1. Exclusão de arquivo: se o arquivo corresponder a algum padrão em ignore_files, ele será ignorado completamente.
  2. Regras ativas: as regras ativas do arquivo consistem nas regras de ruleset_version (all-v1.0 ou none), além de qualquer regra integrada atribuída a uma gravidade warn ou error em rules ou em um bloco overrides correspondente, além de todas as regras definidas em custom_rules.
  3. Resolução de gravidade: para cada regra ativa, a primeira das seguintes configurações que especifica uma gravidade tem precedência: o último bloco overrides correspondente, depois o bloco global rules, depois o severity da regra personalizada e, por fim, a gravidade padrão (error).
  4. Regras desativadas: as regras cuja gravidade resolvida é disabled são ignoradas para esse arquivo.

Exemplo: arquivo de configuração

O exemplo a seguir mostra um arquivo lkmlstyle.yaml completo que demonstra a seleção de conjunto de regras de linha de base, exclusões de arquivos, personalizações de regras globais, modificações no escopo e regras 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"

Escopo e resultados da validação

As seções a seguir descrevem quais arquivos o Style Validator verifica e como os resultados da validação são informados:

Arquivos validados

  • Somente arquivos .lkml e .lookml no projeto raiz são validados. Projetos de dependência importados (local ou remota) não são validados.
  • Cada arquivo é validado com base no próprio conteúdo. As instruções include: não são seguidas, e os objetos extraídos por uma instrução include: não são validados como parte do arquivo de inclusão.
  • As execuções de CI acionadas por jobs de CI do dbt Cloud validam a ramificação LookML de produção em vez de uma ramificação de desenvolvimento.

Comportamento e saída de aprovação ou reprovação

  • Uma execução do Style Validator só falha se pelo menos um diagnóstico tiver a gravidade error. Os avisos por si só não causam falha na execução.
  • Na página de resultados da execução de CI, cada resultado de diagnóstico inclui o nome da regra, o caminho, o número da linha, um trecho de contexto e um link para a documentação da regra. Para mais informações sobre como executar suítes e conferir resultados, consulte Executar suítes de integração contínua e Conferir os resultados de uma execução de CI.
  • Um arquivo de configuração inválido produz um único erro invalid-config no arquivo de configuração na linha 1, e a execução da validação falha.

Validação incremental

Para ativar a validação incremental do Style Validator, marque a caixa de seleção Somente erros incrementais (ativada por padrão) na seção Style Validator ao criar ou editar um conjunto de integração contínua.

Quando a validação incremental está ativada, o Style Validator informa apenas violações novas na sua ramificação de desenvolvimento:

  1. Ele valida o branch de desenvolvimento.
  2. Ele valida a ramificação de destino usando o arquivo de configuração da ramificação de desenvolvimento.
  3. Ele informa apenas as violações que ainda não estão presentes na ramificação de destino.

Observe o seguinte comportamento quando a validação incremental está ativada:

  • Violações preexistentes na ramificação de destino não causam falha na execução.
  • Como o arquivo de configuração da ramificação de desenvolvimento é usado para validar as duas ramificações, uma mudança de configuração na ramificação de desenvolvimento não pode ocultar violações preexistentes nem fazer com que o LookML preexistente apareça como novas violações por conta própria.
  • A ramificação de desenvolvimento precisa conter um arquivo de configuração lkmlstyle.yaml (ou lkmlstyle.yml). Caso contrário, a execução vai falhar com um erro de configuração ausente.

Quando a opção Somente erros incrementais está desativada, todas as violações encontradas na ramificação validada são informadas.

Catálogo de regras integradas

A tabela a seguir lista todas as 25 regras padrão integradas disponíveis no conjunto de regras all-v1.0:

Nome da regra Entidade de destino Resumo da regra
average-measure-name-prefix Medida As métricas com type: average ou average_distinct precisam começar com avg_ ou average_.
boolean-dimension-name-prefix Dimensão As dimensões sim/não precisam começar com is_, has_ ou does_.
count-measure-name-prefix Medida As métricas com type: count ou count_distinct precisam começar com count_.
dimension-group-name-suffix Grupo de dimensão Os grupos de dimensão não podem terminar com _at, _date ou _time.
dimension-label-redundant-yes-no Dimensão Os rótulos de dimensão "Sim/Não" não podem incluir um marcador de sim/não, como (Yes / No) ou (yes/no) (qualquer capitalização ou espaçamento).
dimension-name-snake-case Dimensão Os nomes de dimensões e grupos de dimensões precisam estar em letras minúsculas snake_case.
explore-fields-presence Explorar As análises detalhadas precisam definir a propriedade fields:.
explore-label-presence Explorar As análises detalhadas precisam definir uma propriedade label: explícita.
includes-wildcard-usage Incluir As instruções include: não podem usar caracteres curinga para arquivos de visualização (como *.view.lkml ou /views/*.view). Outros caracteres curinga não são sinalizados.
join-relationship-presence Participar As declarações de exploração join: precisam especificar um relationship:.
measure-name-snake-case Medida Os nomes das métricas precisam estar em letras minúsculas snake_case.
measure-sql-table-reference Medida As medidas precisam referenciar dimensões usando ${dimension_name}, não ${TABLE}.column.
numeric-measure-value-format-presence Medida As métricas com type: count, sum, average ou number precisam especificar value_format: ou value_format_name:.
pdt-view-name-prefix Ver As tabelas derivadas persistentes (TDPs) precisam começar com pdt_. Uma visualização é considerada uma PDT se o derived_table dela define datagroup_trigger, sql_trigger_value, interval_trigger ou persist_for ou define materialized_view: yes.
primary-key-first-dimension Dimensão A dimensão da chave primária precisa ser a primeira definida na visualização.
primary-key-visibility Dimensão As dimensões da chave primária precisam ser ocultadas (hidden: yes).
sql-table-name-uniqueness Ver Várias visualizações não devem apontar para o mesmo sql_table_name.
sum-measure-name-prefix Medida As métricas com type: sum ou sum_distinct precisam começar com sum_ ou total_.
view-dimension-order Ver As dimensões em uma visualização precisam ser organizadas em ordem alfabética.
view-label-presence Ver As visualizações precisam definir um label: explícito.
view-measure-order Ver As métricas em uma visualização precisam ser organizadas em ordem alfabética.
view-name-snake-case Ver Os nomes das visualizações precisam estar em letras minúsculas snake_case. É permitido um + inicial para refinamentos.
view-primary-key-presence Ver As visualizações com sql_table_name ou derived_table (e sem extends) precisam definir uma chave primária.
visible-dimension-description-presence Dimensão As dimensões visíveis precisam ter um description:.
visible-measure-description-presence Medida As medidas visíveis precisam ter um description:.

Solução de problemas

As seções a seguir descrevem problemas comuns de configuração e variações de sintaxe compatíveis ao resolver problemas do Style Validator:

Erros de configuração

Os problemas a seguir são rejeitados quando o arquivo de configuração é carregado e são informados como um erro invalid-config:

  • Chaves de nível superior ou chaves desconhecidas em uma configuração de regra.
  • Um schema_version ou ruleset_version ausente ou um valor não aceito para qualquer um dos parâmetros.
  • Gravidades escalares abreviadas, como rule-name: warn.
  • Um bloco de substituição com files ou rules ausente ou vazio, ou uma configuração de regra dentro de um bloco de substituição sem severity.
  • Um nome de regra desconhecido em um bloco de substituição.
  • Uma regra personalizada com um nome duplicado de outra regra personalizada ou integrada.
  • Uma chave específica do tipo usada no rule_type errado (por exemplo, order_by em uma regra pattern_match).
  • Uma expressão regular inválida.
  • Um parâmetro order_by ausente (para regras de order) ou unique_property (para regras de unique).
  • Um valor position diferente de first (para regras first_child).
  • Um ! inicial sem aspas em uma chave de filtro, como !hidden: true, que é uma sintaxe de tag YAML inválida e faz com que o arquivo de configuração não seja analisado.

Problemas de configuração silenciosos

  • Nomes de regras com erros de ortografia no bloco rules global são ignorados silenciosamente.
  • Nomes de tipos do LookML com erros de ortografia em select, filters, parent_filters, requires_child, forbidden_child ou order_by não geram um erro. Em vez disso, a regra nunca corresponde (ou, para requires_child, sempre falha).
  • Especificar match e should_not_match ou requires_child e forbidden_child: apenas o primeiro parâmetro de cada par é aplicado, e o segundo é ignorado.
  • Especificar parent_filters em uma regra first_child não tem efeito e é ignorado.
  • Os filtros correspondem apenas às propriedades declaradas explicitamente no arquivo LookML, não aos valores padrão da LookML. Consulte Sintaxe de filtragem.
  • Os padrões de expressão regular em regras pattern_match são correspondências de substrings não ancoradas, a menos que você as ancore com ^ e $ (consulte pattern_match).

Variações de sintaxe aceitas

  • Os valores de severity e rule_type não diferenciam maiúsculas de minúsculas.
  • rule_type: pattern é aceito como um alias de pattern_match.
  • Os espaços em branco iniciais e finais em ruleset_version são ignorados.