always_join

Uso

explore: explore_name {
  always_join: [
    view_name,
    view_name,
    ...
  ]
}

Hierarquia Arquivo de modelo explore always_join

Valor padrão Nenhum Aceita Colchetes contendo uma lista de nomes de visualizações separados por vírgulas Regras especiais É necessário associar uma visualização ao explore antes de usá-lo em always_join

Definição

always_join força a inclusão de uma ou mais junções no SQL gerado pelo Looker, mesmo que o usuário não tenha selecionado um campo dessa visualização unida. É possível usar várias junções com uma lista separada por vírgulas, como [view_name_a, view_name_b, etc].

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. Ao usar always_join, você pode forçar a ocorrência de junções, não importa o que aconteça.

always_join pode ser útil quando uma junção é executada com o parâmetro type e não é um LEFT JOIN. Nesse caso, a junção pode ser fundamental para limitar corretamente as linhas retornadas.

Exemplos

Verifique se member está sempre associado a event, mesmo que o usuário não escolha um campo de member. Isso limita os resultados para analisar apenas eventos gerados por membros:

explore: event {
  always_join: [member]
  join: member {
    sql_on: ${event.member_id} = ${member.id} ;;
    type: inner
  }
}

Verifique se member e payment estão sempre unidos a event, mesmo que o usuário não escolha um campo de nenhuma dessas visualizações. Isso limita os resultados a eventos gerados por membros que já pagaram:

explore: event {
  always_join: [member, payment]
  join: member {
    sql_on: ${event.member_id} = ${member.id} ;;
    type: inner
  }
  join: payment {
    sql_on: ${member.payment_id} = ${payment.id} ;;
    type: inner
  }
}

Desafios comuns

Uma visualização precisa ser associada a uma análise detalhada antes de ser referenciada em always_join.

Para colocar uma visualização em always_join, verifique se ela está associada à Análise detalhada em que always_join está sendo usado. Por exemplo, isso não vai funcionar:

explore: event {
  always_join: [member]
}

Aqui, a visualização member não foi unida a event e, portanto, não está disponível para uso em always_join.

Informações importantes

Não aplique lógica de negócios em junções, se possível

A abordagem padrão do Looker para junção é usar um LEFT JOIN sempre que possível. Nos exemplos anteriores, evitamos um LEFT JOIN para que a lógica de negócios possa ser aplicada na própria junção. Em um dos exemplos, criamos uma análise que incluía apenas os eventos associados a membros:

explore: event {
  always_join: [member]
  join: member {
    sql_on: ${event.member_id} = ${member.id} ;;
    type: inner
  }
}

A maneira preferida de executar isso no Looker é usar um LEFT JOIN para reunir dados de eventos e de membros:

explore: event {
  join: member {
    sql_on: ${event.member_id} = ${member.id} ;;
  }
}

Em seguida, crie uma dimensão que pode ser definida como "sim" ou "não" para analisar apenas eventos de membros:

dimension: is_member_event {
  type: yesno
  sql: ${member.id} IS NOT NULL ;;
}

Essa abordagem oferece aos usuários a flexibilidade de analisar todos os eventos ou apenas os de membros. Você não forçou os usuários a analisar apenas eventos de membros usando a junção.

Quando uma análise detalhada inclui always_join, o valor padrão de full_suggestions muda para yes

Quando uma análise detalhada inclui o parâmetro always_join, o valor padrão de full_suggestions muda para yes. Isso faz com que a consulta de sugestões seja executada usando a lógica da Análise detalhada, o que significa que always_join será aplicado para restringir as sugestões retornadas, limitando a lista apenas aos dados que o usuário deve ter acesso.

Se você definir manualmente full_suggestions como no, a consulta de sugestão de filtro não será executada.