sql_always_where

Utilisation

explore: explore_name {
  sql_always_where: ${created_date} >= '2017-01-01' ;;
}
Hiérarchie
explore
sql_always_where
Valeur par défaut
Aucun

Acceptation
Condition WHERE SQL utilisant des noms de dimensions et/ou des noms de colonnes SQL

Règles spéciales
Si vous référencez un nom de colonne SQL dans sql_always_where qui fait partie d'une vue jointe plutôt que de l'exploration, il est important d'utiliser le paramètre always_join ou de référencer un nom de champ à la place.

Définition

sql_always_where vous permet d'appliquer une restriction de requête que les utilisateurs ne peuvent pas modifier. La restriction sera insérée dans la clause WHERE du code SQL sous-jacent généré par Looker pour toutes les requêtes sur l'exploration où sql_always_where est utilisé. Outre les requêtes exécutées par les humains, la restriction s'applique alors aux tableaux de bord, aux présentations planifiées et aux informations incorporées liées à cette exploration.

La condition peut être rédigée en SQL pur, en utilisant les noms réels des tables et des colonnes de votre base de données. Il peut également utiliser des références Looker telles que :

  • ${view_name.SQL_TABLE_NAME}, qui fait référence à une autre vue Looker ou à une table dérivée. Notez que dans cette référence, SQL_TABLE_NAME est une chaîne littérale, qu'il est donc inutile de remplacer.
  • ${view_name.field_name}, qui fait référence à un champ Looker. Cette méthode est préférable à la référence directe aux colonnes SQL, car Looker peut inclure automatiquement les jointures nécessaires.

Les conditions sql_always_where ne sont pas visibles par l'utilisateur, sauf s'il examine le code SQL sous-jacent des requêtes qu'il crée lui-même.

Exemples

Empêcher les utilisateurs de visualiser les commandes antérieures au 1er janvier 2012 :

# Using Looker references
explore: order {
  sql_always_where: ${created_date} >= '2012-01-01' ;;
}

# Using raw SQL
explore: order {
  sql_always_where: DATE(created_time) >= '2012-01-01' ;;
}

Empêchez les utilisateurs de consulter les informations client pour Altostrat Corporation :

explore: customer {
  sql_always_where: ${name} <> 'Altostrat Corporation' ;;
}

Empêcher les utilisateurs de consulter les commandes d'Altostrat Corporation :

explore: order {
  sql_always_where: ${customer.name} <> 'Altostrat Corporation' ;;
  join: customer {
    sql_on: ${order.customer_id} = ${customer.id} ;;
  }
}

Difficultés courantes

Si vous utilisez du code SQL brut, vous devrez peut-être utiliser always_join.

Si vous référencez un nom de colonne SQL dans sql_always_where qui fait partie d'une vue jointe, au lieu de l'explorateur, il est important d'utiliser le paramètre always_join. Considérez l'exemple suivant :

explore: order {
  sql_always_where: customer.name <> 'Altostrat Corporation' ;;
  join: customer {
    sql_on: ${order.customer_id} = ${customer.id} ;;
  }
}

Dans ce cas, sql_always_where fait référence à une colonne de la vue customer jointe, et non à l'exploration order. Étant donné que sql_always_where sera appliqué à chaque requête, il est important que customer soit également joint à chaque requête.

Lorsque Looker génère du code SQL pour une requête, il tente de créer le code SQL le plus propre possible et n'utilise que les jointures nécessaires pour les champs qu'un utilisateur sélectionne. Dans ce cas, Looker ne joindrait customer que si un utilisateur sélectionnait un champ client. En utilisant always_join, vous pouvez forcer la jointure à se produire quoi qu'il arrive.

Si vous utilisiez sql_always_where: ${customer.name} <> 'Altostrat Corporation' au lieu de sql_always_where: customer.name <> 'Altostrat Corporation', Looker serait suffisamment intelligent pour effectuer la jointure customer sans que vous ayez à utiliser always_join. C'est pourquoi nous vous encourageons à utiliser des références de champ Looker plutôt que des références SQL brutes lorsque cela est possible.

N'utilisez qu'un seul sql_always_where par exploration.

Vous ne devez avoir qu'un seul sql_always_where dans une définition explore. Placez tous les comportements souhaités dans un seul sql_always_where en utilisant AND et OR si nécessaire.

Bon à savoir

Il existe un paramètre similaire pour la clause SQL HAVING.

Il existe un paramètre très semblable à sql_always_where, appelé sql_always_having, qui fonctionne de la même manière, mais qui applique des conditions à la clause HAVING au lieu de la clause WHERE.

Si vous souhaitez ajouter des filtres que l'utilisateur peut modifier, mais pas retirer, pensez à utiliser always_filter.

Si vous souhaitez forcer les utilisateurs à utiliser un ensemble spécifique de filtres, mais où la valeur par défaut peut être modifiée, essayez plutôt always_filter.

Si vous souhaitez des filtres spécifiques aux utilisateurs qui ne peuvent pas être modifiés, envisagez d'utiliser access_filter.

Si vous souhaitez qu'une exploration comporte des filtres spécifiques à chaque utilisateur et qui ne peuvent en aucun cas être modifiés, vous pouvez utiliser access_filter.

Lorsqu'une exploration inclut sql_always_where, la valeur par défaut de full_suggestions passe à yes.

Lorsqu'une exploration inclut le paramètre sql_always_where, la valeur par défaut de full_suggestions passe à yes. La requête de suggestions s'exécute alors à l'aide de la logique Explorer, ce qui signifie que sql_always_where est appliqué pour affiner les suggestions renvoyées. La liste de suggestions est ainsi limitée aux données auxquelles l'utilisateur est censé avoir accès.

Si vous définissez manuellement full_suggestions sur no, la requête de suggestion de filtre ne s'exécutera pas.