joins_obrigatórios

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 Nenhuma Aceita Colchetes com uma lista separada por vírgulas de mesclagens para esta exploração Regras 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âmetro required_joins dessa mesclagem fará com que view_name_2 seja unido à exploração.

Os principais casos de uso de required_joins:

• Estilo de sintaxe antigo com sql_on
• Necessidade ou desejo de criar 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 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.