case_sensitive (pour les explorations)

Cette page fait référence au paramètre case_sensitive qui fait partie d'une exploration.

case_sensitive peut également être utilisé dans un modèle, comme décrit sur la page de documentation du paramètre case_sensitive (pour les modèles).

case_sensitive peut également être utilisé dans une dimension, comme décrit sur la page de documentation du paramètre case_sensitive (pour les champs).

Utilisation

explore: explore_name {
  case_sensitive: yes
}
Hiérarchie
explore
case_sensitive
Valeur par défaut
yes, si le dialecte de la base de données accepte le paramètre

Acceptation
Booléen (yes ou no)

Définition

case_sensitive détermine si les filtres seront sensibles à la casse dans une exploration donnée. Tous les filtres associés à l'exploration sont concernés, y compris ceux ajoutés dans l'UI d'exploration, l'UI de tableau de bord et le paramètre filters.

Par défaut, case_sensitivity est activé et les filtres sont sensibles à la casse. Toutefois, certains dialectes ne sont pas compatibles avec ce paramètre, comme décrit dans la section case_sensitive n'est pas compatible avec certains dialectes SQL de cette page.

case_sensitive fonctionne en ajustant la clause WHERE du code SQL généré par Looker. Lorsque case_sensitive est activé, les filtres sont exprimés avec = ou LIKE, par exemple :

WHERE name = 'bob'
WHERE name LIKE '%bob%'

Lorsque case_sensitive est désactivé, les filtres sont exprimés avec ILIKE (ou équivalent), par exemple :

WHERE name ILIKE 'bob'

Exemples

Rendez tous les filtres sensibles à la casse pour l'exploration Produit :

explore: product {
  case_sensitive: yes
}

Rendez tous les filtres non sensibles à la casse pour l'exploration Client :

explore: customer {
  case_sensitive: no
}

Difficultés courantes

case_sensitive n'est pas compatible avec certains dialectes SQL.

Par défaut, case_sensitivity est activé et les filtres sont sensibles à la casse. Si votre dialecte SQL n'est pas compatible avec le paramètre case_sensitive, la sensibilité à la casse variera en fonction de la configuration de votre base de données, qui n'est généralement pas sensible à la casse.

Pour que Looker prenne en charge case_sensitive dans votre projet Looker, votre dialecte de base de données doit également le prendre en charge. Le tableau suivant indique les dialectes qui prennent en charge case_sensitive dans la dernière version de Looker :

Dialecte Compatibilité
Actian Avalanche
Amazon Athena
Amazon Aurora MySQL
Amazon Redshift
Amazon Redshift 2.1+
Amazon Redshift Serverless 2.1+
Apache Druid
Apache Druid 0.13+
Apache Druid 0.18+
Apache Hive 2.3+
Apache Hive 3.1.2+
Apache Spark 3+
ClickHouse
Cloudera Impala 3.1+
Cloudera Impala 3.1+ with Native Driver
Cloudera Impala with Native Driver
DataVirtuality
Databricks
Denodo 7
Denodo 8 & 9
Dremio
Dremio 11+
Exasol
Google BigQuery Legacy SQL
Google BigQuery Standard SQL
Google Cloud PostgreSQL
Google Cloud SQL
Google Spanner
Greenplum
HyperSQL
IBM Netezza
MariaDB
Microsoft Azure PostgreSQL
Microsoft Azure SQL Database
Microsoft Azure Synapse Analytics
Microsoft SQL Server 2008+
Microsoft SQL Server 2012+
Microsoft SQL Server 2016
Microsoft SQL Server 2017+
MongoBI
MySQL
MySQL 8.0.12+
Oracle
Oracle ADWC
PostgreSQL 9.5+
PostgreSQL pre-9.5
PrestoDB
PrestoSQL
SAP HANA
SAP HANA 2+
SingleStore
SingleStore 7+
Snowflake
Teradata
Trino
Vector
Vertica

Bon à savoir

Vous pouvez créer une recherche sensible à la casse dans MySQL.

Il est possible de créer une recherche sensible à la casse dans MySQL, même si MySQL n'est pas compatible avec le paramètre case_sensitive. Dans MySQL, certains types de données (appelés chaînes binaires) stockent le texte sous forme de série de nombres. La casse du texte a une incidence sur les nombres utilisés. Par conséquent, si vous convertissez votre texte en chaîne binaire, vous pouvez effectuer des recherches sensibles à la casse. Exemple :

dimension: will_NOT_be_case_sensitive {
  sql: ${TABLE}.something ;;
}

dimension: will_be_case_sensitive {
  sql: CAST(${TABLE}.something AS BINARY) ;;
}