sql_on

Uso

explore: view_name_1 {
join: view_name_2 {
sql_on: ${view_name_1.id} = ${view_name_2.id} ;;
}
}
Hierarquia
sql_on
Valor padrão
Nenhuma

Aceita
Uma cláusula ON SQL

Regras especiais
sql_on, sql_foreign_key e foreign_key não podem ser usados ao mesmo tempo dentro do mesmo join

Definição

sql_on estabelece uma relação de mesclagem entre uma visualização e sua exploração, com base em uma cláusula ON do SQL fornecida por você.

Para LookML, a ordem das condições em sql_on não importa. Portanto, sql_on: ${order.user_id} = ${user.id} ;; e sql_on: ${user.id} = ${order.user_id} ;; são equivalentes. É possível colocar as condições em qualquer ordem, a menos que a ordem seja relevante para o dialeto SQL do banco de dados.

Uma visualização pode ser mesclada diretamente a uma exploração ao usar sql_on ou pode ser mesclada com uma segunda visualização que já esteja associada a ela.

Veja um exemplo do primeiro caso em que uma visualização é mesclada diretamente ao recurso Explorar:

explore: order {
  join: customer {
    sql_on: ${order.customer_id} = ${customer.id} ;;
  }
}

O SQL que o Looker geraria a partir desse LookML é:

SELECT    ...
FROM      order
LEFT JOIN customer
ON        order.customer_id = customer.id

No segundo caso, uma visualização é mesclada a uma exploração por uma visualização intermediária que já está associada a ela. Veja um exemplo:

explore: order_items {
  join: order {
    sql_on: ${order_items.order_id} = ${order.id} ;;
  }
  join: customer {
    sql_on: ${order.customer_id} = ${customer.id} ;;
  }
}

Aqui, customer não pode ser vinculado diretamente a order_items. Em vez disso, ele precisa ser mesclado por order. O SQL que o Looker geraria a partir desse LookML é:

SELECT    ...
FROM      order_items
LEFT JOIN order
ON        order_items.order_id = order.id
LEFT JOIN customer
ON        order.customer_id = customer.id

Para fazer isso funcionar, é possível ver que precisamos apenas usar os nomes de visualização corretos em nossas referências de campo. Como customer precisa se associar a um campo no order, referenciamos ${order.customer_id}.

Em alguns modelos mais antigos, é possível ver campos referenciados com a sintaxe view_name.native_column_name. Embora isso ainda funcione, usar a sintaxe ${view_name.looker_dimension_name} tem uma vantagem importante: você pode evitar a necessidade do parâmetro required_joins. Esse conceito é explicado em mais detalhes na seção Usar required_joins quando a sintaxe ${view_name.looker_dimension_name} não puder ser usada nesta página.

Mesclagens condicionais

Também é possível permitir que a entrada do usuário seja usada no sql_on. Embora existam vários motivos para fazer isso, otimizar a velocidade da consulta em bancos de dados MPP (como o Redshift) é um caso de uso importante, conforme descrito neste tópico da comunidade.

Para adicionar entradas do usuário à condição de mesclagem, primeiro crie um filtro para a entrada. Esses tipos de filtro são descritos em mais detalhes na página Filtros com modelo. A forma básica é:

view: view_name {
  filter: filter_name {
    type: number | datetime | date | string
  }
}

Depois de adicionar um filtro para coletar a entrada do usuário, use-o no parâmetro sql_on desta forma:

{% condition view_name.filter_name %} view_name.dimension_name {% endcondition %}

Exemplo:

explore: order {
  join: customer {
    sql_on:
      ${order.customer_id} = ${customer.id} AND
      {% condition customer.creation_date_filter %} customer.created_at {% endcondition %} ;;
  }
}

Isso deve ser interpretado para significar: definir customer.created_at igual ao valor de customer.creation_date_filter.

Como usar variáveis líquidas _in_query, _is_selected e _is_filtered

As variáveis líquidas _in_query, _is_selected e _is_filtered podem ser úteis quando usadas com o parâmetro sql_on. Eles permitem que você modifique as relações de mesclagem com base nos campos que um usuário selecionou para a consulta. Exemplo:

explore: dates {
  join: dynamic_order_counts {
    sql_on:
      ${dynamic_order_counts.period} =
      {% dynamic if dates.reporting_date._in_query %}
        ${dates.date_string}
      {% elsif dates.reporting_week._in_query %}
        ${dates.week_string}
      {% dynamic else %}
        ${dates.month_string}
      {% dynamic endif %} ;;
  }
}

Examples

Mescle a visualização chamada customer ao Explorar chamada order, combinando a dimensão customer_id de order com a dimensão id de customer:

explore: order {
  join: customer {
    sql_on: ${order.customer_id} = ${customer.id} ;;
  }
}

Mescle a visualização customer ao Explorar chamado order_items pela visualização chamada order. Combine a dimensão customer_id de order com a dimensão id de customer. Combine a dimensão order_id de order_items com a dimensão id de order. Isso seria especificado da seguinte maneira:

explore: order_items {
  join: order {
    sql_on: ${order_items.order_id} = ${order.id} ;;
  }
  join: customer {
    sql_on: ${order.customer_id} = ${customer.id} ;;
  }
}

Mescle as visualizações order e inventory_items ao order_items. Combine a dimensão inventory_id de order_items com a dimensão id de inventory_item. Combine a dimensão order_id de order_items com a dimensão id de order. Isso seria especificado da seguinte maneira:

explore: order_items {
  join: order {
    sql_on: ${order_items.order_id} = ${order.id} ;;
  }
  join: inventory_item {
    sql_on: ${order_items.inventory_id} = ${inventory_item.id} ;;
  }
}

Informações úteis

Usar required_joins quando a sintaxe ${view_name.looker_dimension_name} não puder ser usada

Ao referenciar campos em sql_on com a sintaxe ${view_name.looker_dimension_name}, você não precisa se preocupar em usar required_joins.

No entanto, alguns modelos mais antigos ainda usam a sintaxe view_name.native_column_name. Também há alguns casos em que não é possível usar a sintaxe ${view_name.looker_dimension_name}, como quando você quer aplicar SQL personalizado.

Nessas situações, talvez seja necessário usar required_joins. Eles são discutidos com mais detalhes na página de documentação do parâmetro required_joins.