Utilisation
explore: explore_name {
conditionally_filter: {
filters: [field_name: "filter expression", field_name: "filter expression", ...]
unless: [field_name, field_name, ...]
}
}
|
Hiérarchie
conditionally_filter |
Valeur par défaut
Aucun
Acceptation
Une ou plusieurs spécifications de filtre d'un nom de champ et d'une expression de filtre Looker, ainsi qu'une liste d'un ou plusieurs noms de champ dans la section unless
|
Définition
Le paramètre conditionally_filter vous permet de définir un ensemble de filtres par défaut que les utilisateurs peuvent remplacer si ils appliquent au moins un filtre d'une deuxième liste que vous définissez.
Ce paramètre sert généralement à empêcher les utilisateurs de créer accidentellement des requêtes très volumineuses qui pourraient être trop coûteuses à exécuter sur votre base de données. Par exemple, vous pouvez forcer un utilisateur à limiter sa requête à la semaine précédente, sauf s'il a explicitement demandé une plage de dates plus large.
Les filtres appliqués dans conditionally_filter s'affichent pour l'utilisateur une fois sa requête exécutée. Les utilisateurs peuvent modifier la valeur par défaut value que vous avez définie, mais ils ne peuvent pas supprimer complètement le filtre, sauf s'ils appliquent au moins l'un des filtres que vous spécifiez dans le sous-paramètre unless.
Les noms de champs que vous utilisez peuvent être le nom d'une dimension ou d'une measure.
Pour faire référence à une dimension ou à une mesure qui fait partie d'une vue jointe plutôt que de cette exploration, utilisez view_name.field_name.
Exemples
Prenons l'exemple suivant :
explore: order {
conditionally_filter: {
filters: [id: "123", customer.id: "678,789"]
unless: [date]
}
join: customer {
sql_on: ${order.customer_id} = ${customer.id} ;;
}
}
Dans ce cas, le filtre id fait référence au champ id de l'exploration appelée order. Le filtre customer.id fait référence au champ id de la vue customer. Les deux filtres seront appliqués, sauf si l'utilisateur définit une date de commande dans l'interface utilisateur Explorer. Cet exemple montre également que vous pouvez exiger plusieurs filtres.
La valeur par défaut que vous spécifiez peut accepter ces types d'expressions.
Vous pouvez également forcer l'utilisateur à utiliser un filtre ID de commande (avec une valeur par défaut de "123" qu'il peut modifier) à moins qu'il n'applique un filtre Date de la commande :
explore: order {
conditionally_filter: {
filters: [id: "123"]
unless: [date]
}
}
Vous pouvez également forcer l'utilisateur à utiliser un filtre ID de commande (avec une valeur par défaut de "123" ou "234" qu'il peut modifier) à moins qu'il n'applique un filtre Date de la commande ou Heure de la commande :
explore: order {
conditionally_filter: {
filters: [id: "123,234"]
unless: [date, time]
}
}
Vous pouvez également forcer l'utilisateur à utiliser un filtre ID de commande (valeur par défaut "123") et un filtre Ville du client (valeur par défaut "Chicago"), sauf s'il applique un filtre Date de la commande ou Date du client :
explore: order {
conditionally_filter: {
filters: [id: "123", customer.city: "Chicago"]
unless: [date, customer.date]
}
join: customer {
sql_on: ${order.customer_id} = ${customer.id} ;;
}
}
Difficultés courantes
Un utilisateur ne peut pas supprimer tous les filtres lorsque conditionally_filter est utilisé.
Il n'est pas possible d'exécuter une requête sans aucun filtre lorsque conditionally_filter est utilisé. Un utilisateur doit utiliser les filtres conditionnels que vous spécifiez ou ses propres filtres de la liste unless.
conditionally_filter avec une dimension type: time dans un groupe place les autres dimensions du groupe dans le sous-paramètre unless.
Si le field que vous spécifiez dans conditionally_filter est une dimension temporelle qui fait partie d'un groupe de dimensions, Looker traitera toutes les autres dimensions de ce groupe comme si elles étaient soumises à un sous-paramètre unless pour ce filtre conditionnel, même si vous n'incluez pas de sous-paramètre unless.
Les deux blocs de code LookML suivants sont interprétés de la même manière. Ici, conditionally_filter est appliqué à une dimension temporelle event_date qui fait partie du groupe de dimensions event. Aucune condition unless n'est spécifiée, mais Looker traitera les autres dimensions du groupe event comme si elles avaient été spécifiées avec le sous-paramètre unless.
Bloc LookML 1 :
explore: logs {
# Make sure there is always a filter on event_date, event_week, event_month or event_year
# Default to the last complete day of data
conditionally_filter: {
filters: [logs.event_date: "1 days ago for 1 day"]
}
view: logs {
# Combine the partition date filters and the time filters into a single field group.
dimension_group: event {
type: time
timeframes: [date,week,month,year]
sql: _PARTITIONTIME ;;
}
}
Bloc LookML 2 :
explore: logs {
# Make sure there is always a filter on event_date, event_week, event_month or event_year
# Default to the last complete day of data
conditionally_filter: {
filters: [logs.event_date: "1 days ago for 1 day"]
unless: [event_week, event_month, event_year]
}
view: logs {
# Combine the partition date filters and the time filters into a single field group.
dimension_group: event {
type: time
timeframes: [date,week,month,year]
sql: _PARTITIONTIME ;;
}
}
Looker interprète les deux blocs LookML de la même manière, même si seul le deuxième bloc LookML applique explicitement le sous-paramètre unless aux autres dimensions du groupe event.
Bon à savoir
Il existe une méthode pour appliquer conditionally_filter à un sous-ensemble d'utilisateurs.
Pour appliquer un filtre conditionnel à certains utilisateurs, mais pas à d'autres, vous pouvez utiliser les autorisations d'accès au modèle. Vous devez créer deux modèles : l'un dans lequel conditionally_filter est utilisé et l'autre dans lequel il ne l'est pas. Vous pouvez ensuite accorder l'accès aux modèles appropriés pour chaque utilisateur.
Si vous souhaitez utiliser conditionally_filter sans unless, utilisez simplement always_filter.
Pour forcer les utilisateurs à utiliser un ensemble de filtres spécifique, mais leur permettre de modifier la valeur par défaut, utilisez plutôt always_filter.
Si vous souhaitez créer des filtres qui ne peuvent pas être modifiés du tout, envisagez d'utiliser sql_always_where.
Si vous souhaitez qu'une exploration comporte des filtres identiques pour tous les utilisateurs et que vous ne voulez pas qu'ils puissent en modifier la valeur, utilisez sql_always_where.
Si vous souhaitez des filtres spécifiques à l'utilisateur 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, mais qui ne peuvent pas être supprimés ni modifiés, utilisez access_filter.