Outil de validation SQL en intégration continue

Le validateur SQL d'intégration continue (CI) vérifie que les dimensions de vos explorations s'exécutent correctement sur votre base de données. Pour ce faire, le programme de validation SQL exécute une série de requêtes sur les explorations de votre projet LookML.

Par défaut, le validateur SQL effectue les tâches suivantes :

1. Pour chaque exploration de votre projet, le programme de validation SQL exécute une requête d'exploration qui inclut toutes les dimensions de l'exploration.
2. Si Looker renvoie une erreur pour la requête d'exploration, le programme de validation SQL exécute alors une requête d'exploration distincte pour chaque dimension de l'exploration.

Si vous ne souhaitez pas que le validateur SQL teste chaque dimension de chaque exploration, vous pouvez effectuer une ou plusieurs des opérations suivantes :

• Configurez le programme de validation SQL pour qu'il n'interroge que certaines explorations.
• Configurez le programme de validation SQL pour exclure certaines explorations.
• Configurez le validateur SQL pour ignorer vos dimensions LookML définies avec hidden: yes.
• Ajoutez un commentaire ou un tag ci: ignore au LookML d'une dimension pour empêcher le programme de validation SQL d'inclure la dimension dans ses requêtes d'exploration.

Pour en savoir plus sur les options que vous pouvez configurer lorsque vous créez ou modifiez une suite d'intégration continue, consultez la section Options du validateur SQL de cette page. Pour savoir comment exécuter le validateur SQL, consultez la page de documentation Exécuter des suites d'intégration continue.

Sur la page des résultats d'exécution, l'outil de validation SQL affiche chaque erreur SQL, classée par dimension et par exploration, avec un lien vers le code LookML problématique et un lien Explorer à partir d'ici pour le débogage :

Consommation des ressources

Le programme de validation SQL est conçu pour consommer le moins de ressources possible dans Looker et dans votre entrepôt de données. Toutes les requêtes du programme de validation SQL incluent une clause LIMIT 0 et WHERE 1=2. Ces clauses indiquent au planificateur de requêtes de votre entrepôt de données de ne pas traiter les données, mais de vérifier la validité du code SQL.

Avec BigQuery, par exemple, ce type de requête est semblable à l'exécution d'une requête dry run dans BigQuery. Pour BigQuery, les requêtes LIMIT 0 n'analysent pas les données. Vous ne devriez donc pas être facturé pour les requêtes exécutées par le validateur SQL.

Exclure des dimensions de la validation SQL

Vous pouvez exclure certaines dimensions de la validation SQL, telles que les dimensions qui dépendent d'un paramètre, car la valeur du paramètre sera nulle lors de la validation et entraînera toujours une erreur SQL.

Vous pouvez également exclure les dimensions qui n'ont pas de paramètre sql, telles que les dimensions de type: distance, type: location ou type: duration.

Pour exclure une dimension de la validation SQL, vous pouvez modifier son code LookML de l'une des deux manières suivantes :

• Vous pouvez ajouter une instruction ci: ignore dans le paramètre tags de la définition LookML de la dimension, comme illustré dans l'exemple suivant :

  dimension: addresses {
    sql: ${TABLE}.addresses ;;
    tags: ["ci: ignore"]
  }
  

• Vous pouvez ajouter le commentaire -- ci: ignore au champ sql du LookML de votre dimension, comme illustré dans l'exemple suivant :

  dimension: addresses {
    sql:
      -- ci: ignore
      ${TABLE}.addresses ;;
  }
  

Conseil : Pour assurer la rétrocompatibilité des projets LookML qui utilisaient auparavant l'intégration continue Spectacles, l'intégration continue Looker accepte également spectacles: ignore pour les tags et les commentaires SQL.

Intégration continue et connexions à la base de données OAuth

Si votre projet LookML utilise une connexion de base de données configurée pour OAuth, les utilisateurs du compte de service d'intégration continue automatisée ne peuvent pas suivre le flux OAuth interactif requis pour s'authentifier auprès de la base de données. Cela entraîne l'échec du programme de validation SQL avec une erreur OAuth log in required.

Pour utiliser le programme de validation SQL d'intégration continue, appliquez l'une des solutions suivantes :

• Configurez la connexion à la base de données pour utiliser un compte de service : modifiez le paramètre Authentification de la connexion à la base de données pour utiliser un compte de service (tel que les identifiants par défaut de l'application) au lieu d'OAuth.
• Utiliser un modèle non OAuth pour l'intégration continue : créez un modèle LookML qui utilise une connexion à une base de données non OAuth et importez vos autres modèles dans celui-ci. Assurez-vous que l'utilisateur Looker CI a accès à ce nouveau modèle.

Options du programme de validation SQL

Vous pouvez spécifier plusieurs options lorsque vous créez ou modifiez une suite d'intégration continue pour configurer l'exécution de SQL Validator. Les options sont décrites dans les sections suivantes de cette page :

• Explorations à interroger
• Explorations à exclure
• Échec rapide
• Ignorer les dimensions masquées
• Requêtes simultanées
• Validation incrémentielle

Explorations à interroger

Par défaut, le programme de validation SQL exécute la validation SQL sur tous les modèles et explorations de votre projet LookML.

Vous pouvez utiliser le champ Explorations à interroger pour spécifier les explorations et les modèles que vous souhaitez inclure dans la validation SQL.

Vous pouvez spécifier des explorations au format suivant : model_name/explore_name

Veuillez noter les points suivants :

• Pour model_name, utilisez le nom du fichier de modèle sans l'extension .model.lkml. Par exemple, pour spécifier le modèle défini dans thelook.model.lkml, vous devez saisir thelook.
• Pour explore_name, utilisez le explore_name du paramètre LookML explore. Par exemple, pour spécifier l'exploration définie comme explore: users dans votre projet LookML, vous devez saisir users.
• Vous pouvez créer une liste d'éléments séparés par une virgule pour spécifier plusieurs explorations.
• Vous pouvez utiliser le caractère générique * dans model_name ou explore_name.

Voici quelques exemples :

• Pour spécifier uniquement l'exploration Users définie avec explore: users dans le fichier thelook.model.lkml, vous devez saisir ce qui suit :

  thelook/users
  

• Pour spécifier les explorations nommées users et orders dans le fichier thelook.model.lkml, vous devez saisir ce qui suit :

  thelook/users, thelook/orders
  

• Pour spécifier toutes les explorations de thelook.model.lkml, saisissez ce qui suit :

  thelook/*
  

• Pour spécifier toutes les explorations nommées users dans tous les modèles de votre projet, saisissez ce qui suit :

  */users
  

Explorations à exclure

Par défaut, le programme de validation SQL exécute la validation SQL sur tous les modèles et explorations de votre projet LookML.

Vous pouvez utiliser le champ Explorations à exclure pour spécifier les explorations et les modèles que vous souhaitez exclure de la validation SQL.

Vous pouvez spécifier des explorations au format suivant : model_name/explore_name

Pour en savoir plus sur la façon de spécifier des explorations pour le validateur SQL, consultez la section Explorations à interroger.

Les échecs rapides

Par défaut, le programme de validation SQL exécute une requête par exploration avec toutes les dimensions de la requête. Si cette requête d'exploration échoue, le validateur SQL effectue une requête d'exploration pour chaque dimension de l'exploration individuellement.

Pour une validation plus rapide, vous pouvez activer l'option Échec rapide afin que le validateur SQL n'exécute que la requête initiale d'une exploration, c'est-à-dire celle qui contient toutes les dimensions à la fois. Si cette requête renvoie une erreur, le validateur SQL l'affiche dans les résultats d'exécution de l'intégration continue et passe à l'exploration suivante à valider.

Lorsque l'option Échec rapide est activée, la validation est généralement plus rapide. Toutefois, les résultats du validateur SQL n'afficheront que la première erreur pour chaque exploration, même si plusieurs dimensions peuvent comporter des erreurs. Cela signifie qu'après avoir corrigé la première erreur, la prochaine exécution du validateur SQL peut afficher une erreur supplémentaire.

Remarque : Le mode Échec rapide n'est pas compatible avec les exécutions de validation incrémentale, car des requêtes de dimension individuelles sont nécessaires pour exposer les erreurs incrémentales spécifiques à une branche de développement du projet.

Ignorer les dimensions masquées

Activez le champ Ignorer les éléments masqués si vous souhaitez que le programme de validation SQL ignore les dimensions LookML que vos développeurs Looker ont définies avec hidden: yes. Le programme de validation SQL exclura ces dimensions de ses requêtes d'exploration lors de la validation.

Conseil : Vous pouvez également exclure des dimensions de la validation SQL en ajoutant un commentaire ou un tag au code LookML de la dimension. Pour en savoir plus, consultez la section Exclure des dimensions de la validation SQL.

Requêtes simultanées

Par défaut, le programme de validation SQL n'exécute pas plus de 10 requêtes à la fois pour éviter de surcharger votre instance Looker. Vous pouvez utiliser le champ Requêtes simultanées pour spécifier un nombre maximal différent de requêtes que le programme de validation SQL peut exécuter simultanément.

La valeur maximale du champ Simultanéité des requêtes est limitée au paramètre Nombre maximal de requêtes simultanées pour cette connexion de votre connexion à la base de données.

Si vous remarquez un ralentissement de votre instance Looker lors de l'exécution de la validation SQL, vous pouvez réduire cette valeur.

Astuce : Vous pouvez également limiter la validation à une exploration ou à un modèle spécifiques à l'aide de l'option Explorations à interroger, ou exclure des explorations et des modèles à l'aide de l'option Explorations à exclure. Vous pouvez également activer l'option Échec rapide pour limiter la validation SQL à une seule requête par exploration.

Validation incrémentielle

La validation incrémentale est une méthode permettant de détecter les erreurs qui sont propres à une branche de développement spécifique et qui n'existent pas déjà en production. La validation incrémentielle aide les développeurs à trouver et à corriger les erreurs dont ils sont responsables sans être distraits par les erreurs existantes dans le projet. Elle peut également accélérer la validation, en particulier pour les projets LookML qui contiennent de nombreuses explorations.

Pour la validation incrémentielle, le programme de validation SQL n'exécute que les requêtes d'exploration qui ont changé entre une version de développement (la référence de base) et la version en production (la référence cible). Le validateur SQL ne renvoie que les erreurs propres à la version de développement, même si la version en production comporte elle-même des erreurs.

Dans les résultats du programme de validation, le programme de validation SQL indique chaque exploration qui a été ignorée, car son code SQL compilé n'a pas été modifié dans la branche ou le commit en cours de validation. Pour obtenir un exemple de résultats de validation incrémentale, consultez Afficher les résultats de la validation incrémentale.

Vous pouvez activer la validation incrémentielle pour le programme de validation SQL en cochant la case Uniquement les erreurs incrémentielles dans la section Programme de validation SQL lorsque vous créez ou modifiez une suite d'intégration continue.

Notez les points suivants concernant la validation incrémentielle :

• Le paramètre de validation incrémentale n'est pas appliqué lorsque le programme de validation SQL valide la branche de production elle-même (par exemple, lorsque vous y effectuez manuellement des exécutions). Lors de la validation de la branche de production, le programme de validation SQL effectue une validation complète.
• Le mode Échec rapide n'est pas compatible avec les exécutions de validation incrémentale, car des requêtes de dimension individuelles sont nécessaires pour exposer les erreurs incrémentales spécifiques à une branche de développement du projet.