Tieni presente che stai visualizzando la documentazione di Looker. Per la documentazione di Looker Studio, visita https://support.google.com/looker-studio.

Questa pagina è stata tradotta dall'API Cloud Translation.

Riutilizzo del codice con estensioni

Questo è un argomento avanzato che presuppone che il lettore abbia una solida conoscenza di LookML.

Panoramica

Man mano che il tuo modello LookML si espande in dimensioni e complessità, diventa sempre più utile riutilizzarlo in più posti. Il parametro extends ti consente di riutilizzare il codice, utile per:

Scrivi codice DRY (don't repeat yourself, non ripeterti), in modo da poter definire le cose in un unico posto, rendendo il codice più coerente e più veloce da modificare
Gestire set di campi diversi per utenti diversi
Condividere pattern di progettazione in parti diverse del progetto
Riutilizzare insiemi di unioni, dimensioni o misure in un progetto

Per estendere un oggetto LookML, crea un nuovo oggetto LookML e aggiungi il parametro extends per indicare che il nuovo oggetto è un'estensione di un oggetto esistente. Ciò significa che il progetto avrà due versioni dell'oggetto LookML. In caso di conflitti, l'oggetto in estensione avrà la precedenza e sostituirà le impostazioni dell'oggetto in fase di estensione. Per maggiori dettagli, consulta la sezione Dettagli di implementazione per extends più avanti in questa pagina.

Scopri i perfezionamenti LookML:l'estensione di una vista o di un'esplorazione è l'ideale per gli scenari in cui vuoi avere più versioni della vista o dell'esplorazione. Ma se il tuo obiettivo è semplicemente quello di modificare una vista o un'esplorazione senza modificare il file LookML che li contiene, ti consigliamo di utilizzare un perfezionamento. Puoi anche utilizzare un parametro extends all'interno di un perfezionamento. Per ulteriori informazioni e casi d'uso, consulta la pagina della documentazione sui perfezionamenti LookML.

Puoi estendere viste, esplorazioni e dashboard LookML:

I modelli non possono essere estesi e non puoi includere un file modello in un altro file modello. Se invece vuoi riutilizzare o estendere le esplorazioni tra i modelli, puoi creare un file di esplorazione separato e poi includerlo in un file del modello.

Consulta gli esempi seguenti di estensione di un'esplorazione e di estensione di una dashboard LookML.

Estensione di un'esplorazione

Ecco un esempio di estensione di un'esplorazione:

explore: customer {
  persist_for: "12 hours"
}

explore: transaction {
  extends: [customer]
  persist_for: "5 minutes"
}

In questo esempio abbiamo un'esplorazione chiamata Cliente e abbiamo creato una seconda esplorazione chiamata Transazione che la estende. Tutto ciò che è in Cliente, ad esempio le unioni, verrà incluso in Transazione. Tutto ciò che si trova in Transazione rimarrà in Transazione.

Tuttavia, tieni presente che esiste un conflitto: l'esplorazione Cliente indica che l'impostazione persist_for deve essere di 12 ore, ma l'esplorazione Transazioni indica che deve essere di 5 minuti. Per l'esplorazione Transazione verrà utilizzata l'impostazione persist_for: "5 minutes" perché sovrascrive l'impostazione dell'esplorazione che sta estendendo.

Estensione di una dashboard LookML

Per estendere una dashboard LookML, sia la dashboard che l'estensione devono essere incluse nel file del modello. Se una dashboard che utilizza il parametro extends è inclusa in un file del modello senza la dashboard di base che estende, verrà visualizzato un errore di convalida di LookML che indica che la dashboard di base non può essere trovata (tra gli altri errori).

Ecco un esempio di file della dashboard:

File: faa.dashboard.lookml

- dashboard: faa
  title: FAA Dashboard
  layout: newspaper
  elements:
  - title: Aircraft Location
    name: Aircraft Location
    model: e_faa
    explore: aircraft
    type: looker_map
    fields:
    - aircraft.zip
    - aircraft.count
    sorts:
    - aircraft.count desc
    limit: 500
    query_timezone: America/Los_Angeles
    series_types: {}
    row: 0
    col: 0
    width: 8
    height: 6

Possiamo creare un nuovo file della dashboard LookML ed estendere la dashboard FAA aggiungendo un nuovo riquadro:

File: faa_additional.dashboard.lookml

- dashboard: faa_additional
  title: FAA Additional
  extends: faa
  elements:
  - title: Elevation Count
    name: Elevation Count
    model: e_faa
    explore: airports
    type: looker_scatter
    fields:
    - airports.elevation
    - airports.count
    sorts:
    - airports.count desc
    limit: 500
    query_timezone: America/Los_Angeles
    row: 0
    col: 8
    width: 8
    height: 6

Poiché estende la dashboard FAA, la dashboard FAA Additional includerà tutti i riquadri definiti nel file faa.dashboard.lookml. Inoltre, la dashboard FAA Additional avrà tutti i riquadri definiti nel proprio file faa_additional.dashboard.lookml.

Il modo più semplice per creare una dashboard LookML è ottenere il codice LookML da una dashboard definita dall'utente. Puoi utilizzare questa tecnica anche per ottenere il codice LookML per i singoli riquadri della dashboard. Se utilizzi questo metodo, assicurati che le posizioni dei riquadri non si sovrappongano. Negli esempi faa.dashboard.lookml e faa_additional.dashboard.lookml, i riquadri sono entrambi nella riga superiore della dashboard, indicata da row: 0:

File: faa.dashboard.lookml


    row: 0
    col: 0
    width: 8
    height: 6

Tuttavia, il nuovo riquadro che stiamo aggiungendo alla dashboard FAA Additional è in col: 8, quindi viene visualizzato accanto al riquadro della dashboard estesa:

File: faa_additional.dashboard.lookml


    row: 0
    col: 8
    width: 8
    height: 6

È facile non accorgersene, poiché questi elementi si trovano in file della dashboard diversi. Pertanto, se aggiungi riquadri a una dashboard estesa, assicurati di verificare la presenza di conflitti di posizionamento tra i riquadri della dashboard estesa e quelli della dashboard estesa.

Richiesta di estensione in corso...

Puoi utilizzare il parametro extension: required per contrassegnare un oggetto LookML come richiede estensione, il che significa che l'oggetto non può essere utilizzato da solo. Un oggetto con extension: required non è visibile agli utenti singolarmente. ma solo come punto di partenza che può essere esteso da un altro oggetto LookML. Il parametro extension è supportato per esplorazioni, visualizzazioni e dashboard di LookML.

Un explore con extension: required non può essere utilizzato come explore_source per un test dei dati. Lo strumento di convalida LookML genererà un errore che indica che non è possibile trovare explore_source.

Utilizzo dei metadati per visualizzare le estensioni di un oggetto

Puoi fare clic su un parametro explore o view nell'IDE di Looker e utilizzare il riquadro dei metadati per visualizzare eventuali estensioni dell'oggetto o per vedere quale oggetto estende. Per informazioni, consulta la pagina della documentazione Metadati per gli oggetti LookML.

Dettagli di implementazione per `extends`

Questi sono i passaggi che Looker esegue quando estende un oggetto LookML:

Copia l'oggetto che viene esteso: Looker crea una copia del LookML per la vista, l'esplorazione o la dashboard LookML che viene estesa. Questa nuova copia è l'oggetto ing.
Unisci il LookML delle due copie: Looker unisce il LookML dell'oggetto esteso all'oggetto di estensione.
Risolvi i conflitti tra le copie: per la maggior parte, se un elemento LookML è definito sia nell'oggetto estesoed che in quelloing, viene utilizzata la versione nell'oggetto in estensione. Tuttavia, in altri casi, le estensioni combinano i valori dei parametri invece di eseguire l'override dei valori. Per informazioni, consulta la sezione Combinazione di parametri in questa pagina.
Applica il LookML: una volta risolti tutti i conflitti, Looker interpreta il LookML risultante utilizzando la logica standard. In altre parole, Looker utilizzerà tutte le impostazioni predefinite e le ipotesi standard come per qualsiasi altra visualizzazione, esplorazione o dashboard LookML.

Le sezioni seguenti mostrano le specifiche di questi passaggi, estendendo una visualizzazione come esempio. Ecco il codice LookML per la nostra visualizzazione di base, la visualizzazione Utente:

view: user {
  suggestions: yes

  dimension: name {
    sql: ${TABLE}.name ;;

  }
  dimension: status {
    sql: ${TABLE}.status ;;
    type: number
  }
}

Ecco il codice LookML per la visualizzazione Utente con estensioni di età, che estende la visualizzazione Utente:

include: "/views/user.view"

view: user_with_age_extensions {
  extends: [user]
  suggestions: no

  dimension: age {
    type: number
    sql: ${TABLE}.age ;;
  }

  dimension: status {
    type: string
  }
}

Passaggio 1: copia il codice LookML

In questo caso, la visualizzazione user viene estesa alla visualizzazione user_with_age_extensions. Poiché user è la visualizzazione che viene estesa, ne viene creata una copia prima dell'unione. Il fatto che sia stata realizzata una copia non è particolarmente importante in questo caso; è importante sapere che la vista originale di user non ha subito modifiche ed è utilizzabile normalmente.

Passaggio 2: unisci le copie

Il passaggio successivo prevede che tutto il LookML della vista estesa (user) venga unito alla vista estesa (user_with_age_extensions). È importante comprendere la natura di questa unione, che è semplicemente un'unione di oggetti LookML. In pratica, ciò significa che qualsiasi codice LookML scritto esplicitamente viene unito, ma i valori di LookML predefiniti che non hai scritto non vengono uniti. In un certo senso, è in realtà solo il testo del LookML che viene messo insieme e nessuno del significato di quel testo.

Passaggio 3: risolvi i conflitti

Il terzo passaggio consiste nel risolvere eventuali conflitti tra le viste unite.

Nella maggior parte dei casi, se un elemento LookML viene definito sia nell'oggetto allungatoed che in quello in quelloing, viene utilizzata la versione nell'oggetto in espansione. Tuttavia, in altri casi, le estensioni combinano i valori dei parametri invece di eseguire l'override dei valori. Per informazioni, consulta la sezione Combinazione di parametri in questa pagina.

Nel caso dell'esempio user_with_age_extensions, nessuno dei parametri è additivo e non sono specificate opzioni di elenco o sql parole chiave speciali, quindi i valori parametro nella vista estesa andranno a sostituire i valori parametro nella visualizzazione estesa:

Il nome della vista estesa (user_with_age_extensions) sostituisce il nome della vista estesa (user).
Il valore in espansione per suggestions: no sostituisce il valore esteso suggestions: yes.
La vistaestensibile ha una dimensione denominata age, che non esiste nella vistaestesa (nessun conflitto).
La visualizzazione estesa ha una dimensione denominata name, che non esiste nella visualizzazione estesa (nessun conflitto).
Il valore type: string della dimensione status nella vista estesa sostituisce il valore di type: number nella vista estesa.
La dimensione status ha un parametro sql che non esiste nella visualizzazione estesa (nessun conflitto).

Il fatto che i valori LookML predefiniti non siano ancora presi in considerazione è importante, perché non devi commettere l'errore di pensare che i conflitti tra i valori predefiniti vengano risolti. In realtà, vengono semplicemente ignorati in questo passaggio. Ecco perché dobbiamo aggiungere esplicitamente parametri aggiuntivi quando estendiamo gli oggetti:

Quando espandi una visualizzazione, aggiungiamo i parametri sql_table_name e include.
Quando estendi un'esplorazione, aggiungi i parametri view_name e view_label.

In questo esempio specifico, non abbiamo aggiunto sql_table_name alla visualizzazione Utente, il che causerà alcuni problemi nel passaggio successivo.

Passaggio 4: interpreta il codice LookML come di consueto

Nel passaggio finale, il LookML risultante viene interpretato come normale, inclusi tutti i valori predefiniti. In questo particolare esempio, la vista LookML risultante viene interpretata come segue:

include: "/views/user.view"

view: user_with_age_extensions {
  suggestions: no

  dimension: age {
    type: number
    sql: ${TABLE}.age ;;
  }

  dimension: name {
    sql: ${TABLE}.name ;;
  }

  dimension: status {
    sql: ${TABLE}.status ;;
    type: string
  }
}

Nota che il LookML risultante include view: user_with_age_extensions, ma nessun parametro sql_table_name. Di conseguenza, Looker suppone che il valore di sql_table_name sia uguale al nome della vista.

Il problema è che probabilmente non esiste una tabella nel nostro database chiamata user_with_age_extensions. Questo è il motivo per cui dobbiamo aggiungere un parametro sql_table_name a qualsiasi vista che verrà estesa. L'aggiunta di view_name e view_label alle esplorazioni che verranno estese evita problemi simili.

Combinazione di estensioni

Esistono alcuni modi per sfruttare gli oggetti LookML con le estensioni:

Un oggetto può estendere più altri oggetti.
Un oggetto esteso può essere esteso a sua volta.
Le estensioni possono essere utilizzate nei perfezionamenti (per saperne di più, consulta la pagina della documentazione sui perfezionamenti LookML).

Per visualizzare un esempio di caso d'uso avanzato e leggere i suggerimenti per la risoluzione dei problemi, vedi la pagina Risolvere i problemi di un esempio di caso d'uso avanzato di extends.

Estensione di più oggetti contemporaneamente

Puoi estendere contemporaneamente più dashboard, visualizzazioni o esplorazioni. Ad esempio:

explore: orders {
  extends: [user_info, marketing_info]
}
# Also works for dashboards and views

La procedura di estensione funziona esattamente come descritto nell'esempio di implementazione, ma esiste una regola aggiuntiva su come vengono risolti i conflitti. In caso di conflitti tra i vari elementi elencati nel parametro extends, viene data la priorità agli elementi elencati per ultimi. Quindi, nell'esempio precedente, in caso di conflitti tra user_info e marketing_info, l'esplorazione marketing_info vincerebbe.

Concatenamento di più estensioni

Puoi anche concatenare tutte le estensioni che vuoi. Ad esempio:

explore: orders {
  extends: [user_info]
  ...
}
explore: user_info {
  extends: [marketing_info]
  ...
}

Anche in questo caso, la procedura di estensione funziona esattamente come descritto nell'esempio di implementazione, con un'ulteriore regola per la risoluzione dei conflitti. In caso di conflitti, la priorità viene assegnata all'ultimo elemento della catena di estensioni. In questo esempio:

orders avrà la priorità su user_info e marketing_info.
user_info avrà la priorità su marketing_info.

Parametri combinati

Per la maggior parte, se un elemento LookML è definito sia nell'oggetto esteso sia nell'oggetto di estensione, viene utilizzata la versione nell'oggetto di estensione. Questo è successo nell'esempio di implementazione in questa pagina.

Tuttavia, nei seguenti casi, le estensioni combineranno i valori parametro invece di eseguire l'override dei valori:

Per i parametri additivi
Con la parola chiave dell'elenco EXTENDED*
Con la parola chiave ${EXTENDED} per il parametro sql

Alcuni parametri sono additivi

In molti casi, se l'oggetto che estende contiene lo stesso parametro dell'oggetto esteso, i valori dell'oggetto che estende sostituiranno i valori del parametro dell'oggetto esteso. Tuttavia, le estensioni possono essere additive per alcuni parametri, il che significa che i valori dell'oggetto in estensione vengono utilizzati insieme ai valori dell'oggetto esteso.

I seguenti parametri sono additivi:

Per dimensioni e misure:
Per i parametri:
- allowed_value
Per le tabelle derivate:
Per le visualizzazioni:
- extends
Per le esplorazioni:

Nell'esempio seguente, la vista carriers ha una dimensione name con un parametro link:

view: carriers {
  sql_table_name: flightstats.carriers ;;

  dimension: name {
    sql: ${TABLE}.name ;;
    type: string
    link: {
      label: "Google {{ value }}"
      url: "http://www.google.com/search?q={{ value }}"
      icon_url: "http://google.com/favicon.ico"
    }
  }
}

Ed ecco la visualizzazione carriers_extended, che estende la visualizzazione carriers. La visualizzazione carriers_extended ha anche una dimensione name con impostazioni diverse nel parametro link:


include: "/views/carriers.view.lkml"

view: carriers_extended {
  extends: [carriers]

  dimension: name {
    sql: ${TABLE}.name ;;
    type: string
    link: {
      label: "Dashboard for {{ value }}"
      url: "https://docsexamples.dev.looker.com/dashboards/307?Carrier={{ value }}"
      icon_url: "https://www.looker.com/favicon.ico"
    }
  }
}

Nella visualizzazione carriers_extended, i due parametri link sono additivi, pertanto la dimensione name mostrerà entrambi i link.

Opzioni aggiuntive con elenchi

Quando lavori con gli elenchi, puoi scegliere di combinarli, invece di lasciare che l'elenco degli oggetti in estensione risulti il vincitore. Considera questa semplice estensione con un elenco in conflitto denominato animals:

view: pets {
  extends: fish
  set: animals {
    fields: [dog, cat]
  }
}
view: fish {
  set: animals {
    fields: [goldfish, guppy]
  }
}

In questo caso la vista pets sta eseguendo l'estensione e quindi vincerà, facendo in modo che animals contenga [dog, cat]. Tuttavia, utilizzando l'insieme speciale EXTENDED*, puoi combinare gli elenchi:

view: pets {
  extends: fish
  set: animals {
    fields: [dog, cat, EXTENDED*]
  }
}
view: fish {
  set: animals {
    fields: [goldfish, guppy]
  }
}

Ora l'elenco animals conterrà [dog, cat, goldfish, guppy].

Combinazione anziché sostituzione durante la risoluzione dei conflitti

Nella maggior parte dei casi, in caso di conflitti durante l'estensione, l'oggetto che esegue l'estensione ha la precedenza. Ad esempio, consideriamo questa semplice estensione:

view: product_short_descriptions {
  extends: products
  dimension: description {
    sql: ${TABLE}.short_description ;;
  }
}
view: products {
  dimension: description {
    sql: ${TABLE}.full_description ;;
  }
}

Puoi vedere che esiste un conflitto del parametro sql all'interno della dimensione description. In genere, la definizione da product_short_descriptions semplicemente sovrascrive la definizione da products perché è in corso l'estensione.

Tuttavia, se vuoi, puoi anche scegliere di combinare le definizioni. A questo scopo, utilizzerai la parola chiave ${EXTENDED} come segue:

view: product_short_descriptions {
  extends: products
  dimension: description {
    sql: LEFT(${EXTENDED}, 50) ;;
  }
}
view: products {
  dimension: description {
    sql: ${TABLE}.full_description ;;
  }
}

Ora il conflitto del parametro sql verrà gestito in modo diverso. Anziché la definizione vincente di product_short_descriptions, prenderà la definizione da products e la inserirà dove viene utilizzato ${EXTENDED}. La definizione risultante di description in questo caso sarà: LEFT(${TABLE}.full_description, 50).

Aspetti da considerare

Progetti con localizzazione

Quando estendi un oggetto, tieni presente che le regole di localizzazione si applicano anche alle tue estensioni. Se stai estendendo un oggetto e poi definisci nuove etichette o descrizioni, devi fornire definizioni di localizzazione nei file di stringhe di impostazioni internazionali del tuo progetto. Per saperne di più, consulta la pagina della documentazione Localizzazione del modello LookML.