Uso
cancel_grouping_fields: [
full_Scope_field,
full_Scope_field,
...
]
}
Hierarquia
cancel_grouping_fields |
Valor padrão
NenhumaAceita
Colchetes com uma lista separada por vírgulas de nomes de campos com escopo completoRegras especiais
|
Definição
cancel_grouping_fields
permite que você impeça que o Looker adicione uma cláusula GROUP BY
ao SQL gerado. Se algum dos campos especificados for incluído pelo usuário, o Looker não vai ser agrupado. Essa funcionalidade normalmente é usada para melhorar o desempenho da consulta em tabelas muito grandes. Exceto em circunstâncias raras e únicas, só inclua campos exclusivos em cada linha da tabela, como a chave primária.
Como as medidas do Looker representam funções agregadas de SQL, que exigem uma cláusula GROUP BY
para funcionar, cancel_grouping_fields
não funcionará com nenhum relatório que inclua medidas. Além disso, cancel_grouping_fields
não funciona quando relationship: one_to_many
ou relationship: many_to_many
são usados.
Por fim, os campos listados precisam ter o escopo completo. Em outras palavras, eles precisam ser escritos como view_name.field_name
, e não apenas como field_name
.
Examples
Não agrupe os resultados se o usuário escolher o Código do pedido no seletor de campo:
explore: order {
cancel_grouping_fields: [order.id]
}
Não agrupe os resultados se o usuário escolher ID do pedido ou Hash do pedido no seletor de campo:
explore: order {
cancel_grouping_fields: [order.id, order.hash]
}
Não agrupe os resultados se o usuário escolher ID de pessoa ou ID de DNA no seletor de campo:
explore: person {
cancel_grouping_fields: [person.id, dna.id]
join: dna {
sql_on: ${person.dna_id} = ${dna.id} ;;
relationship: one_to_one
}
}
Desafios comuns
cancel_grouping_fields
exige nomes de campo com escopo completo.
A maioria dos parâmetros no Looker assumirá um nome de visualização com base no lugar em que o parâmetro for usado, se você mesmo escrever um nome de campo. cancel_grouping_fields
não funciona dessa forma e exige que você escreva o nome da visualização e do campo.
Por exemplo, você pode pensar que isso funcionaria e que id
seria interpretado como o ID do pedido que aparece no seletor de campo:
explore: order {
cancel_grouping_fields: [id]
}
No entanto, esse não é o caso, e um erro vai aparecer. Em vez disso, escreva:
explore: order {
cancel_grouping_fields: [order.id]
}
cancel_grouping_fields
é acionado quando qualquer campo especificado é escolhido, mas não exige que todos os campos sejam escolhidos
Se você especificar mais de um campo em cancel_grouping_fields
, o agrupamento será cancelado se um usuário selecionar qualquer campo na lista. O usuário não precisa selecionar todos os campos da lista. Por isso, as chaves primárias de várias colunas não funcionam com cancel_grouping_fields
.
Informações úteis
cancel_grouping_fields
não é necessário para que o Looker funcione corretamente. É para melhorar a consulta em tabelas grandes
Ao escrever o SQL manualmente, a maioria das pessoas não vai incluir uma cláusula GROUP BY
, a menos que seja absolutamente necessária. O Looker também evita cláusulas GROUP BY
desnecessárias em alguns casos. Se uma das dimensões na sua consulta tiver sido definida como a chave primária (usando o parâmetro primary_key
) do recurso Explorar, a cláusula GROUP BY
vai ser descartada.
No entanto, há alguns casos em que outra dimensão, que não é a chave primária, ainda define uma linha exclusiva. Nesses casos, o Looker pode gerar uma GROUP BY
desnecessária, porque o agrupamento por dimensões é uma parte fundamental de como o Looker funciona. Na maioria dos casos, isso não vai causar problemas. Os resultados serão exibidos como esperado e mais rápidos.
No entanto, em algumas tabelas muito grandes, cláusulas desnecessárias de GROUP BY
podem aumentar o tempo de consulta. Essa é a situação ideal para usar cancel_grouping_fields
.