Convalidatore dello stile di integrazione continua

Lo strumento di convalida dello stile di integrazione continua (CI) applica gli standard di codifica, le convenzioni di denominazione e le best practice strutturali di LookML nel tuo progetto LookML utilizzando lo strumento di analisi dello stile di LookML. Controllando i file LookML in base a un insieme configurabile di regole di stile, lo strumento di convalida dello stile aiuta il tuo team a mantenere una codebase pulita, coerente e leggibile.

Per eseguire lo strumento di convalida dello stile, devi aggiungere un file di configurazione denominato lkmlstyle.yaml (o lkmlstyle.yml) alla directory principale del repository del progetto LookML. Per informazioni dettagliate sulla configurazione del linter di stile, consulta la sezione File di configurazione di questa pagina.

Per informazioni sulla configurazione e l'esecuzione di Style Validator in una suite CI e sulla visualizzazione dell'output di convalida, consulta le pagine di documentazione Creazione di una suite di integrazione continua, Esecuzione di suite di integrazione continua e Visualizzazione dei risultati di un'esecuzione CI.

Prima di iniziare

Per utilizzare lo strumento di convalida dello stile nell'integrazione continua, devi disporre di quanto segue:

File di configurazione

Per eseguire lo strumento di convalida dello stile in Looker CI è obbligatorio un file di configurazione. Quando viene eseguito lo strumento di convalida dello stile, controlla automaticamente la directory principale del repository del progetto LookML per un file di configurazione nel seguente ordine di priorità:

  1. lkmlstyle.yaml
  2. lkmlstyle.yml

Se entrambi i file esistono nella directory principale, lkmlstyle.yaml ha la precedenza e lkmlstyle.yml viene ignorato.

Se non viene trovato lkmlstyle.yaml o lkmlstyle.yml nella directory principale del progetto (e non viene passata alcuna configurazione personalizzata tramite l'API), l'esecuzione della convalida dello stile non riesce e viene visualizzato l'errore "No style validator configuration provided".

Per eseguire tutte le 25 regole integrate standard con le impostazioni predefinite, puoi utilizzare le seguenti informazioni di configurazione minime nel file lkmlstyle.yaml:

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

In caso contrario, puoi personalizzare il file di configurazione. Il file di configurazione può contenere i seguenti parametri di primo livello:

Parametro Tipo Obbligatorio? Predefinito Descrizione
schema_version Numero intero Sì Nessuno Versione dello schema di configurazione. La versione 1 è l'unica supportata e deve essere specificata in modo esplicito.
ruleset_version Stringa Sì Nessuno Set di regole di base da ereditare. Valori supportati: "all-v1.0", "none".
ignore_files Elenco di stringhe No [] Pattern glob dei file da escludere completamente dalla convalida dello stile.
rules Mappa No {} Personalizzazioni globali (severity e version) per le singole regole. Puoi anche attivare le regole integrate che il set di regole di base non include e modificare la gravità delle regole personalizzate. Per esempi, consulta la sezione Personalizzazioni delle regole.
overrides Elenco delle mappe No [] Override delle regole con ambito che modificano o attivano le gravità per percorsi di file corrispondenti specifici.
custom_rules Elenco delle mappe No [] Regole personalizzate dichiarative definite dall'utente.

ruleset_version

Il parametro ruleset_version definisce le basi della tua strategia di convalida dello stile:

  • "all-v1.0" (consigliato): attiva tutte le 25 regole di stile LookML standard integrate al livello di gravità error. Questa opzione è ideale per i team che vogliono un'applicazione completa della qualità predefinita.
  • "none": inizia con zero regole integrate abilitate. Questa opzione è ideale per i team che vogliono adottare la convalida dello stile in modo incrementale, attivare regole specifiche una alla volta o eseguire solo regole organizzative personalizzate. Per attivare una regola integrata quando ruleset_version è "none", assegna alla regola una gravità warn o error nel blocco rules o in un blocco overrides.

ignore_files

Il parametro ignore_files accetta un elenco di pattern glob per i file che vuoi ignorare completamente durante la convalida dello stile. I file che corrispondono a questi pattern non vengono ispezionati per verificare la presenza di regole integrate o personalizzate.

La sintassi dei caratteri jolly supportata include quanto segue:

  • *: Corrisponde a qualsiasi sequenza di caratteri non separatori all'interno di un singolo livello di directory.
  • **: corrisponde a qualsiasi sequenza di caratteri in più livelli di directory nidificati.
  • ?: corrisponde a qualsiasi singolo carattere.
  • {a,b} e [abc]: corrisponde ad alternative e classi di caratteri (sintassi glob Java).

Le seguenti regole di corrispondenza del percorso si applicano a ogni pattern glob nel file di configurazione, inclusi ignore_files di primo livello, nonché files e ignore_files in overrides:

  • I percorsi sono relativi alla directory radice del progetto. Un ./ o / iniziale viene ignorato.
  • Un pattern senza barra (/) corrisponde a qualsiasi profondità di directory. Ad esempio, *.ignore.lkml corrisponde sia a x.ignore.lkml sia a views/x.ignore.lkml.
  • Un pattern che termina con / corrisponde a tutto ciò che si trova in quella directory.
  • Un pattern che termina con .lkml o .lookml corrisponde anche alle estensioni composte. Ad esempio, *.ignore.lkml corrisponde a x.ignore.view.lkml.

L'esempio seguente esclude i file del fornitore, i file LookML legacy e le dashboard LookML:

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

rules

Puoi utilizzare il blocco rules per regolare la gravità della diagnostica delle singole regole nell'intero progetto:

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

Qualsiasi regola integrata elencata in rules (o in un blocco overrides) con gravità warn o error è attiva, anche quando ruleset_version è impostato su "none". Ad esempio, la seguente configurazione iniziale inizia con ruleset_version: "none" e attiva solo due regole integrate:

schema_version: 1
ruleset_version: "none"

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

Puoi anche utilizzare il blocco rules per modificare la gravità di una regola personalizzata facendo riferimento al suo nome.

severity

Ogni regola può essere configurata con uno dei seguenti livelli di gravità senza distinzione tra maiuscole e minuscole:

  • error: trattata come violazione grave. Gli errori causano l'esito negativo dell'esecuzione dell'integrazione continua.
  • warn: emesso come avviso non bloccante. Gli avvisi vengono visualizzati nei report di esecuzione dell'integrazione continua, ma non causano l'errore dell'esecuzione.
  • disabled: disattiva completamente la regola e la salta durante la convalida.

overrides

Puoi utilizzare il parametro overrides per modificare la gravità delle regole per file o directory specifici senza modificare la gravità nel resto del progetto LookML. Ad esempio, puoi utilizzare overrides per allentare le regole per le visualizzazioni di staging o i modelli legacy, inasprirle per i percorsi critici o attivare regole specifiche solo per determinate directory quando ruleset_version è "none".

Ogni voce dell'elenco overrides supporta i seguenti campi:

Campo Tipo Obbligatorio? Descrizione
files Elenco di stringhe Sì Pattern glob che corrispondono ai file a cui si applica questo blocco di override. Non può essere vuoto.
ignore_files Elenco di stringhe No Pattern glob da escludere da questo blocco di override specifico.
rules Mappa Sì Mappa dei nomi delle regole alle configurazioni di gravità. Non può essere vuoto. È consentito (e richiesto) solo severity nei blocchi di override. I nomi delle regole devono essere nomi di regole personalizzate o integrate validi.

Il seguente esempio disattiva i controlli dell'ordinamento delle dimensioni e declassa gli errori di descrizione mancante ad avvisi per le visualizzazioni e le dashboard legacy:

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

Puoi definire regole personalizzate dichiarative nella sezione custom_rules del file di configurazione per applicare convenzioni di denominazione specifiche dell'organizzazione, pattern architetturali richiesti e governance strutturale.

Ogni definizione di regola personalizzata supporta i seguenti parametri comuni:

Campo Tipo Obbligatorio? Descrizione
name Stringa Sì Identificatore univoco, in formato dash-case per convenzione, ad esempio finance-measure-prefix. Non deve entrare in conflitto con i nomi delle regole integrate o con altre regole personalizzate.
title Stringa Sì Messaggio leggibile segnalato quando si verifica una violazione, formattato come (<rule-name>) <title>.
rule_type Stringa Sì L'archetipo della regola: pattern_match, property, order, first_child o unique. Senza distinzione tra maiuscole e minuscole; pattern è accettato come alias di pattern_match.
severity Stringa No Livello di diagnostica: error (predefinito), warn o disabled. Può essere ignorato da rules e overrides.
rationale Stringa No Documenta il motivo per cui esiste la regola.
select Stringa o elenco No Percorso del nodo dell'albero della sintassi astratta (AST) alla destinazione, ad esempio "view.dimension", "explore" o ["dimension", "dimension_group"]. Se omessa, la regola ha come target ogni nodo che corrisponde a filters.
filters Mappa No Filtri delle proprietà che devono corrispondere al nodo di destinazione, ad esempio primary_key: true.
parent_filters Mappa No Filtri delle proprietà che devono corrispondere all'elemento padre immediato del nodo di destinazione.

Ogni tipo di regola accetta solo le proprie chiavi specifiche del tipo. Le chiavi sconosciute o quelle che appartengono a un tipo di regola diverso (ad esempio order_by in una regola pattern_match) comportano un errore di configurazione.

select

Il parametro select determina quali elementi LookML vengono valutati dalla regola personalizzata:

  • Elemento diretto: scegli come target un tipo di elemento LookML specifico, ad esempio select: "dimension", select: "measure", select: "view", select: "explore", select: "join", select: "model" o select: "include".
  • Percorso gerarchico nidificato: scegli come target gli elementi definiti all'interno di un elemento principale immediato specifico, ad esempio select: "view.dimension" (dimensioni definite all'interno delle visualizzazioni) o select: "explore.join" (join definiti all'interno degli Explore). Il genitore deve essere il genitore immediato e vengono utilizzati solo gli ultimi due segmenti di un percorso (quindi a.b.c si comporta come b.c).
  • Più target: scegli come target più tipi di elementi utilizzando una stringa o un elenco separato da virgole, ad esempio select: "dimension, dimension_group" o select: ["dimension", "dimension_group"].

I nomi di selettori, filtri e elementi secondari sono parole chiave LookML esatte e sensibili alle maiuscole. Un nome scritto in modo errato non viene segnalato come errore di configurazione; al contrario, la regola non corrisponde mai.

filters e parent_filters

Puoi utilizzare filters e parent_filters per perfezionare i nodi di destinazione in base alle proprietà LookML dichiarate esplicitamente nel file LookML.

  • Uguaglianza booleana: corrispondenza delle proprietà booleane dichiarate in modo esplicito, ad esempio primary_key: true o hidden: true.
  • Uguaglianza delle stringhe: corrispondenza esatta dei valori delle stringhe, ad esempio type: "yesno" o type: "count".
  • Elenco di valori: corrisponde a qualsiasi valore in un elenco, ad esempio type: ["string", "number", "date"].
  • Controllo della presenza: verifica se è presente un blocco o una proprietà passando una stringa vuota, ad esempio derived_table: "".
  • Negazione: aggiungi il prefisso ! alla chiave o al valore per negare il filtro. Una chiave negata deve essere racchiusa tra virgolette perché un ! iniziale non racchiuso tra virgolette è una sintassi di tag YAML e impedisce l'analisi del file di configurazione:
    • "!hidden": true o hidden: "!true" corrisponde agli elementi visibili (non nascosti), inclusi i campi che non dichiarano hidden.
    • type: ["!yesno", "!date"] corrisponde a tipi che non sono né yesno né date.

rule_type

Ogni regola personalizzata deve specificare uno dei seguenti cinque archetipi di regole per il parametro rule_type:

pattern_match

Applica pattern di espressioni regolari ai nomi delle entità o ai valori delle proprietà LookML. Devi specificare esattamente uno dei valori match o should_not_match (se sono impostati entrambi, viene applicato solo match e should_not_match viene ignorato automaticamente):

  • match (stringa, espressione regolare): pattern a cui deve corrispondere la destinazione.
  • should_not_match (stringa, espressione regolare): pattern a cui non deve corrispondere il target.

I pattern sono espressioni regolari Java che vengono convalidate quando viene caricato il file di configurazione. La corrispondenza è non ancorata (una corrispondenza di sottostringa); ad esempio, match: "fin_" viene superato per my_fin_total. Utilizza ^ e $ per trovare una corrispondenza con l'intero valore.

Se select ha come target una proprietà anziché un'entità (ad esempio select: "measure.sql" o select: "dimension.label"), l'espressione regolare viene valutata in base al valore della proprietà anziché al nome di un'entità. Le regole integrate measure-sql-table-reference e dimension-label-redundant-yes-no funzionano in questo modo.

Esempio che impone che le misure di valuta terminino 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)$"

Esempio che vieta le dimensioni temporanee o bozza:

- 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

Impone la presenza o il divieto obbligatorio di proprietà secondarie specifiche all'interno degli oggetti LookML. Devi specificare esattamente uno dei valori requires_child o forbidden_child (se sono impostati entrambi, viene applicato solo requires_child e forbidden_child viene ignorato automaticamente):

  • requires_child (stringa o elenco): nome o nomi della proprietà secondaria che devono essere presenti. Quando specifichi un elenco, la regola viene soddisfatta se è presente uno qualsiasi dei figli elencati.
  • forbidden_child (stringa o elenco): nome o nomi della proprietà secondaria che non devono essere presenti. Quando specifichi un elenco, il nodo viene contrassegnato se è presente uno qualsiasi dei figli elencati.
  • child_filters (Map, facoltativo): filtri delle proprietà aggiuntivi che il figlio obbligatorio deve soddisfare.

Esempio che richiede descrizioni per tutte le dimensioni visibili:

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

Esempio che vieta sql_table_name nelle tabelle derivate:

- 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

Impone l'ordinamento alfabetico degli elementi di pari livello all'interno di un contenitore.

  • order_by (stringa, obbligatorio): tipo LookML dei figli fratelli da ordinare, in genere "dimension" o "measure". Vengono confrontati solo gli elementi secondari diretti del nodo selezionato e gli elementi secondari dimension_group non sono inclusi in "dimension".

I nomi vengono confrontati in modo sensibile alle maiuscole e minuscole in base al codice carattere: le lettere maiuscole vengono ordinate prima delle lettere minuscole e _ viene ordinato tra le due.

Esempio che richiede l'elenco delle dimensioni in ordine alfabetico all'interno delle visualizzazioni:

- 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

Impone che un elemento corrispondente a un filtro specifico venga visualizzato come primo elemento secondario della sua categoria.

  • position (stringa, facoltativo): vincolo di posizione. Deve essere "first" (il valore predefinito è "first").

Per le regole first_child, select deve utilizzare il modulo parent.child_type, ad esempio "view.dimension". Il parametro filters identifica il nodo secondario che deve essere visualizzato per primo; non limita i nodi principali controllati. Il parametro parent_filters è accettato dallo schema, ma viene ignorato per questo tipo di regola.

Esempio che richiede la dichiarazione della dimensione della chiave primaria in una visualizzazione:

- 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

Impone l'unicità di un valore di proprietà in tutti i nodi corrispondenti nei file convalidati durante unCI continua.

  • unique_property (stringa, obbligatorio): nome della proprietà che deve avere valori univoci nei nodi corrispondenti, ad esempio "sql_table_name" o "label".

I valori vengono confrontati come stringhe esatte e vengono segnalati sia la prima occorrenza sia ogni duplicato. Se un'esecuzione di convalida controlla solo un sottoinsieme dei file del progetto, i duplicati nei file al di fuori di questo sottoinsieme non vengono rilevati.

Esempio che garantisce nomi di tabelle univoci in tutte le visualizzazioni:

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

Vincoli delle regole personalizzate

Quando crei regole personalizzate, rispetta i seguenti vincoli:

  1. Nessuna collisione con i nomi delle regole integrate: le regole personalizzate non possono riutilizzare alcun nome del catalogo delle regole integrate, ad esempio boolean-dimension-name-prefix o sql-table-name-uniqueness.
  2. Nomi personalizzati univoci: ogni regola personalizzata deve avere un nome distinto all'interno dell'elenco custom_rules.
  3. Formato dash-case: i nomi delle regole devono utilizzare il formato dash-case (lowercase-words-with-hyphens).

Ordine di valutazione della configurazione

Quando lo strumento di convalida dello stile valuta un file LookML, le regole di configurazione vengono applicate nel seguente ordine:

  1. Esclusione file: se il file corrisponde a un pattern in ignore_files, viene ignorato completamente.
  2. Regole attive: le regole attive per il file sono costituite dalle regole di ruleset_version (all-v1.0 o none), più qualsiasi regola integrata a cui è stata assegnata una gravità warn o error in rules o in un blocco overrides corrispondente, più tutte le regole definite in custom_rules.
  3. Risoluzione della gravità: per ogni regola attiva, ha la precedenza la prima delle seguenti impostazioni che specifica una gravità: l'ultimo blocco overrides corrispondente, poi il blocco rules globale, poi il severity della regola personalizzata e infine la gravità predefinita (error).
  4. Regole disattivate: le regole la cui gravità risolta è disabled vengono ignorate per quel file.

File di configurazione di esempio

Il seguente esempio mostra un file lkmlstyle.yaml completo che illustra la selezione del set di regole di base, le esclusioni di file, le personalizzazioni delle regole globali, gli override con ambito e le regole personalizzate:

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

Ambito e risultati della convalida

Le sezioni seguenti descrivono quali file vengono controllati da Style Validator e come vengono riportati i risultati della convalida:

File convalidati

  • Vengono convalidati solo i file .lkml e .lookml nel progetto root. I progetti di dipendenza importati (locali o remoti) non vengono convalidati.
  • Ogni file viene convalidato in base al proprio contenuto. include: non vengono seguite e gli oggetti inseriti tramite un'istruzione include: non vengono convalidati come parte del file di inclusione.
  • Le esecuzioni CI attivate dai job CI dbt Cloud convalidano il ramo LookML di produzione anziché un ramo di sviluppo.

Comportamento e output di superamento o mancato superamento

Convalida incrementale

Puoi attivare la convalida incrementale per lo strumento di convalida dello stile selezionando la casella di controllo Solo errori incrementali (attivata per impostazione predefinita) nella sezione Strumento di convalida dello stile quando crei o modifichi una suite di integrazione continua.

Quando la convalida incrementale è attivata, Style Validator segnala solo le violazioni nuove nel ramo di sviluppo:

  1. Convalida il ramo di sviluppo.
  2. Convalida il ramo di destinazione utilizzando il file di configurazione del ramo di sviluppo.
  3. Vengono segnalate solo le violazioni non ancora presenti nel ramo di destinazione.

Tieni presente il seguente comportamento quando la convalida incrementale è abilitata:

  • Le violazioni preesistenti nel branch di destinazione non causano l'errore dell'esecuzione.
  • Poiché il file di configurazione del ramo di sviluppo viene utilizzato per convalidare entrambi i rami, una modifica alla configurazione del ramo di sviluppo non può nascondere violazioni preesistenti o far apparire il codice LookML preesistente come nuove violazioni.
  • Il ramo di sviluppo deve contenere un file di configurazione lkmlstyle.yaml (o lkmlstyle.yml), altrimenti l'esecuzione non riesce e viene visualizzato un errore di configurazione mancante.

Quando l'opzione Solo errori incrementali è disattivata, viene segnalata ogni violazione rilevata nel ramo convalidato.

Catalogo delle regole integrate

La tabella seguente elenca tutte le 25 regole integrate standard disponibili nel set di regole all-v1.0:

Nome regola Entità target Riepilogo delle regole
average-measure-name-prefix Misura Le metriche con type: average o average_distinct devono iniziare con avg_ o average_.
boolean-dimension-name-prefix Dimensioni Le dimensioni Sì/No devono iniziare con is_, has_ o does_.
count-measure-name-prefix Misura Le metriche con type: count o count_distinct devono iniziare con count_.
dimension-group-name-suffix Gruppo di dimensioni I gruppi di dimensioni non devono terminare con _at, _date o _time.
dimension-label-redundant-yes-no Dimensioni Le etichette delle dimensioni Sì/No non devono includere un marcatore sì/no come (Yes / No) o (yes/no) (con qualsiasi combinazione di maiuscole e minuscole o spaziatura).
dimension-name-snake-case Dimensioni I nomi delle dimensioni e dei gruppi di dimensioni devono essere in lettere minuscole snake_case.
explore-fields-presence Esplora Le esplorazioni devono definire la proprietà fields:.
explore-label-presence Esplora Le esplorazioni devono definire una proprietà label: esplicita.
includes-wildcard-usage Includi Le istruzioni include: non devono utilizzare caratteri jolly per i file di visualizzazione (ad esempio *.view.lkml o /views/*.view). Gli altri caratteri jolly non vengono segnalati.
join-relationship-presence Partecipa Le dichiarazioni di Esplora join: devono specificare un relationship:.
measure-name-snake-case Misura I nomi delle misure devono essere in minuscolo snake_case.
measure-sql-table-reference Misura Le misure devono fare riferimento alle dimensioni utilizzando ${dimension_name}, non ${TABLE}.column.
numeric-measure-value-format-presence Misura Le misure con type: count, sum, average o number devono specificare value_format: o value_format_name:.
pdt-view-name-prefix Visualizza Le tabelle derivate permanenti (PDT) devono iniziare con pdt_. Una visualizzazione viene conteggiata come PDT se il relativo derived_table imposta datagroup_trigger, sql_trigger_value, interval_trigger o persist_for oppure materialized_view: yes.
primary-key-first-dimension Dimensioni La dimensione della chiave primaria deve essere la prima dimensione definita nella vista.
primary-key-visibility Dimensioni Le dimensioni della chiave primaria devono essere nascoste (hidden: yes).
sql-table-name-uniqueness Visualizza Più visualizzazioni non devono puntare esattamente allo stesso sql_table_name.
sum-measure-name-prefix Misura Le metriche con type: sum o sum_distinct devono iniziare con sum_ o total_.
view-dimension-order Visualizza Le dimensioni all'interno di una vista devono essere organizzate in ordine alfabetico.
view-label-presence Visualizza Le viste devono definire un label: esplicito.
view-measure-order Visualizza Le misure all'interno di una visualizzazione devono essere organizzate in ordine alfabetico.
view-name-snake-case Visualizza I nomi delle viste devono essere in lettere minuscole snake_case (è consentito un + iniziale per i perfezionamenti).
view-primary-key-presence Visualizza Le viste con sql_table_name o derived_table (e nessun extends) devono definire una chiave primaria.
visible-dimension-description-presence Dimensioni Le dimensioni visibili devono avere un description:.
visible-measure-description-presence Misura Le misure visibili devono avere un description:.

Risoluzione dei problemi

Le sezioni seguenti descrivono i problemi di configurazione comuni e le varianti di sintassi supportate durante la risoluzione dei problemi del validatore di stile:

Errori di configurazione

I seguenti problemi vengono rifiutati quando viene caricato il file di configurazione e vengono segnalati come errore invalid-config:

  • Chiavi di primo livello sconosciute o chiavi sconosciute all'interno di una configurazione di regola.
  • Un valore schema_version o ruleset_version mancante o non supportato per uno dei due parametri.
  • Gravità scalari abbreviate, ad esempio rule-name: warn.
  • Un blocco di override con files o rules mancante o vuoto oppure una configurazione di regole all'interno di un blocco di override senza severity.
  • Un nome di regola sconosciuto in un blocco di override.
  • Una regola personalizzata il cui nome duplica un'altra regola personalizzata o una regola integrata.
  • Una chiave specifica per il tipo utilizzata nel rule_type errato (ad esempio, order_by in una regola pattern_match).
  • Un'espressione regolare non valida.
  • Parametro order_by mancante (per le regole order) o parametro unique_property mancante (per le regole unique).
  • Un valore position diverso da first (per le regole first_child).
  • Un ! iniziale senza virgolette in una chiave di filtro, ad esempio !hidden: true, che è una sintassi di tag YAML non valida e impedisce l'analisi del file di configurazione.

Problemi di configurazione silenziosa

  • I nomi delle regole con errori ortografici nel blocco rules globale vengono ignorati automaticamente.
  • I nomi dei tipi LookML con errori ortografici in select, filters, parent_filters, requires_child, forbidden_child o order_by non generano un errore. Al contrario, la regola non corrisponde mai (o, per requires_child, ha sempre esito negativo).
  • Se specifichi sia match che should_not_match oppure sia requires_child che forbidden_child, viene applicato solo il primo parametro di ogni coppia e il secondo viene ignorato.
  • La specifica di parent_filters in una regola first_child non ha effetto e viene ignorata.
  • I filtri corrispondono solo alle proprietà dichiarate esplicitamente nel file LookML, non ai valori predefiniti di LookML (vedi Sintassi di filtraggio).
  • I pattern delle espressioni regolari nelle regole pattern_match sono corrispondenze di sottostringhe non ancorate, a meno che non vengano ancorate con ^ e $ (vedi pattern_match).

Varianti di sintassi accettate

  • I valori per severity e rule_type non fanno distinzione tra maiuscole e minuscole.
  • rule_type: pattern è accettato come alias di pattern_match.
  • Gli spazi vuoti iniziali e finali in ruleset_version vengono ignorati.