always_join

Uso

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

Jerarquía Archivo del modelo explore always_join

Valor predeterminado Ninguno Acepta Corchetes que contienen una lista de nombres de vistas separados por comas Reglas especiales Debes unir una vista a explore antes de usarla en always_join.

Definición

always_join fuerza la inclusión de una o más uniones en el código SQL que genera Looker, incluso si el usuario no seleccionó un campo de esa vista unida. Se pueden requerir varias uniones con una lista separada por comas, como [view_name_a, view_name_b, etc].

Cuando Looker genera SQL para una consulta, intenta crear el SQL más limpio posible y solo usará las uniones que sean necesarias para los campos que seleccione un usuario. Si usas always_join, puedes forzar que se produzcan las uniones sin importar qué suceda.

always_join puede ser valioso cuando se ejecuta una unión con el parámetro type y la unión no es un LEFT JOIN. En tal situación, la unión puede ser fundamental para limitar correctamente las filas que se devuelven.

Ejemplos

Asegúrate de que member siempre se una a event, incluso si el usuario no elige un campo de member. Esto limita los resultados para que solo se muestren los eventos generados por miembros:

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

Asegúrate de que member y payment siempre se unan a event, incluso si el usuario no elige un campo de ninguna de esas vistas. Esto limita los resultados para que solo se muestren los eventos generados por miembros que ya pagaron:

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
  }
}

Desafíos habituales

Una vista debe unirse a un Explorar antes de que se pueda hacer referencia a ella en always_join.

Para colocar una vista en always_join, asegúrate de que esté unida a la Exploración en la que se usa always_join. Por ejemplo, esto no funcionará:

explore: event {
  always_join: [member]
}

Aquí, la vista member no se unió a event, por lo que no está disponible para usarse en always_join.

Información importante

No apliques lógica empresarial en las uniones si es posible

El enfoque estándar de Looker para las uniones es usar un LEFT JOIN siempre que sea posible. En los ejemplos anteriores, evitamos un LEFT JOIN para que la lógica empresarial se pueda aplicar dentro de la unión. En uno de los ejemplos, creamos una exploración que incluía solo los eventos asociados con miembros:

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

La forma preferida de ejecutar esto en Looker es usar un LEFT JOIN para obtener datos de eventos y datos de miembros de forma sencilla:

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

Luego, podrías crear una dimensión que podrías configurar como sí o no para analizar solo los eventos de miembros:

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

Este enfoque les brinda a los usuarios la flexibilidad de ver todos los eventos o solo los eventos de los miembros. No obligaste a los usuarios a ver solo los eventos de miembros a través de la unión.

Cuando un Explore incluye always_join, el valor predeterminado de full_suggestions cambia a yes.

Cuando un Explorar incluye el parámetro always_join, el valor predeterminado de full_suggestions cambia a yes. Esto hace que la consulta de sugerencias se ejecute con la lógica de Explorar, lo que significa que se aplicará always_join para reducir las sugerencias que se devuelvan, lo que limitará la lista de sugerencias solo a los datos a los que el usuario debe tener acceso.

Si estableces full_suggestions en no de forma manual, no se ejecutará la consulta de sugerencias de filtros.