Uso
join: view_name_2 { ... }
join: view_name_3 {
required_joins: [
view_name_2
, ...]}
}
Hierarquia
required_joins |
Valor padrão
NenhumaAceita
Colchetes com uma lista separada por vírgulas de mesclagens para esta exploraçãoRegras especiais
Uma visualização precisa ser associada a uma exploração antes que possa ser referenciada no required_joins
|
Definição
required_joins
força um ou mais joins
a serem incluídos no SQL gerado pelo Looker, mesmo se o usuário não tiver selecionado um campo nessa visualização mesclada. Esse comportamento será acionado sempre que o usuário selecionar um campo de uma visualização relacionada especificada por você. Várias mesclagens podem ser necessárias usando uma lista separada por vírgulas, como [join_name_a, join_name_b, ...]
.
Quando o Looker gera SQL para uma consulta, ele tenta criar o SQL mais limpo possível e usa apenas as mesclagens necessárias para os campos selecionados pelo usuário. No exemplo do diagrama de sintaxe na parte superior desta página:
- Se um usuário escolher apenas um campo de
view_name_2
, essa será a única visualização mesclada em "Explorar". - Se um usuário selecionar um campo de
view_name_3
, o parâmetrorequired_joins
dessa mesclagem fará com queview_name_2
seja unido à exploração.
Os principais casos de uso de required_joins
:
Estilo de sintaxe antigo com sql_on
sql_on
não precisa de required_joins
quando é usado com a sintaxe ${view_name.looker_dimension_name}
. No entanto, alguns modelos mais antigos ainda usam a sintaxe view_name.native_column_name
. Exemplo:
explore: order_items {
join: order {
sql_on: order_items.order_id = order.id ;;
}
join: customer {
sql_on: order.customer_id = customer.id ;;
required_joins: [order]
}
}
-
Neste exemplo, sempre que um usuário seleciona um campo do customer
, a visualização order
também precisa ser mesclada para manter a relação de mesclagem adequada. Caso você se esqueça de exigir essas consultas, ainda é possível que o usuário escolha se quer escolher campos de todas as visualizações obrigatórias. No entanto, outras consultas podem resultar silenciosamente em dados inválidos devido à mesclagem incorreta.
Em vez de usar required_joins
, considere modificar o modelo para usar a sintaxe ${view_name.looker_dimension_name}
.
Necessidade ou desejo de escrever SQL bruto
Em alguns casos, não é possível ou não é recomendável usar a sintaxe ${view_name.looker_dimension_name}
com sql_on
. Normalmente, isso acontece porque você quer usar os valores brutos no seu banco de dados e quer evitar transmissões ou outras manipulações que ocorrem com a sintaxe ${view_name.looker_dimension_name}
. Veja um exemplo de uso:
explore: order {
join: user {
sql_on: ${order.user_id} = ${user.id} ;;
}
join: pre_sign_up_events {
from: event
sql_on:
${event.user_id} = ${user.id} AND
event.date BETWEEN user.creation_date AND user.sign_up_date ;;
required_joins: [user]
relationship: one_to_many
}
}
-
Neste exemplo, a junção pre_sign_up_events
depende de datas de user
. Consequentemente, é importante garantir que user
seja mesclado usando required_joins
.
Em vez de usar required_joins
para evitar a transmissão com campos de data ou hora, considere usar o tipo date_raw
e evite usar required_joins
.
Desafios comuns
Uma visualização precisa ser associada a uma exploração antes que possa ser referenciada no required_joins
Para colocar uma visualização no required_joins
, é necessário se conectar ao explore
em que o required_joins
está sendo usado. Por exemplo, isto não funcionará:
explore: order_items {
join: customer {
sql_on: order.customer_id = customer.id ;;
required_joins: [order]
}
}
-
Como order
não faz parte do order_items
, não está disponível para uso no required_joins
.