required_joins

Uso

explore: view_name_1 {
  join: view_name_2 { ... }
  join: view_name_3 {
    required_joins: [view_name_2, ...]
  }
}

Hierarquia Arquivo de modelo explore join required_joins

Valor padrão Nenhum Aceita Colchetes que contêm uma lista separada por vírgulas de junções para esta análise Regras especiais Uma visualização precisa ser associada a uma análise detalhada antes de ser referenciada em required_joins.

Definição

required_joins força a inclusão de um ou mais joins no SQL gerado pelo Looker, mesmo que o usuário não tenha selecionado um campo dessa visualização unida. Esse comportamento é acionado sempre que o usuário seleciona um campo de uma visualização relacionada especificada. É possível usar várias junções com 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 junções necessárias para os campos selecionados por um usuário. No exemplo de diagrama de sintaxe na parte de cima desta página:

• Se um usuário escolher apenas um campo de view_name_2, essa será a única visualização associada à análise detalhada.
• Se um usuário selecionar um campo de view_name_3, o parâmetro required_joins dessa junção fará com que view_name_2 seja unido à análise detalhada.

Os principais casos de uso do required_joins:

• Estilo de sintaxe antigo com sql_on
• Necessidade ou desejo de escrever SQL bruto

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 de customer, a visualização order também precisa ser unida para manter a relação de junção adequada. Se você se esquecer de exigir isso, as consultas ainda poderão funcionar se o usuário escolher campos de todas as visualizações obrigatórias. No entanto, outras consultas podem resultar em dados ruins devido à junção inadequada.

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

Há alguns casos em que 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 banco de dados e evitar qualquer conversão ou outras manipulações que ocorram com a sintaxe ${view_name.looker_dimension_name}. Confira 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. Portanto, é importante garantir que user seja unido usando required_joins.

Em vez de usar required_joins para evitar a conversã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 análise detalhada antes de ser referenciada em required_joins.

Para colocar uma visualização em required_joins, verifique se ela está unida ao explore em que required_joins está sendo usado. Por exemplo, isso não vai funcionar:

explore: order_items {
  join: customer {
    sql_on: order.customer_id = customer.id ;;
    required_joins: [order]
  }
}

Aqui, order não foi associado a order_items e, portanto, não está disponível para uso em required_joins.