always_join

Nutzung

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

Hierarchie Model File explore always_join

Standardwert Keine Akzeptiert Eckige Klammern mit einer durch Kommas getrennten Liste von Ansichtsnamen Besondere Regeln Sie müssen eine Ansicht mit explore verknüpfen, bevor Sie sie in always_join verwenden können.

Definition

Mit always_join werden ein oder mehrere Joins in den von Looker generierten SQL-Code aufgenommen, auch wenn der Nutzer kein Feld aus dieser verbundenen Ansicht ausgewählt hat. Mehrere Joins können mit einer durch Kommas getrennten Liste wie [view_name_a, view_name_b, etc] erforderlich sein.

Wenn Looker SQL für eine Abfrage generiert, wird versucht, den saubersten möglichen SQL-Code zu erstellen. Es werden nur die Joins verwendet, die für die von einem Nutzer ausgewählten Felder erforderlich sind. Mit always_join können Sie erzwingen, dass Joins unabhängig von den Umständen ausgeführt werden.

always_join kann nützlich sein, wenn ein Join mit dem Parameter type ausgeführt wird und der Join kein LEFT JOIN ist. In einer solchen Situation kann der Join entscheidend sein, um die zurückgegebenen Zeilen korrekt einzuschränken.

Beispiele

member muss immer mit event verknüpft werden, auch wenn der Nutzer kein Feld aus member auswählt. Dadurch werden die Ergebnisse auf von Mitgliedern generierte Ereignisse beschränkt:

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

Achten Sie darauf, dass member und payment immer mit event verknüpft werden, auch wenn der Nutzer kein Feld aus einer dieser Ansichten auswählt. Dadurch werden die Ergebnisse auf von Mitgliedern generierte Ereignisse beschränkt, bei denen das Mitglied bereits bezahlt hat:

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

Häufige Herausforderungen

Eine Ansicht muss mit einem Explore verknüpft werden, bevor sie in always_join referenziert werden kann.

Damit eine Ansicht in always_join eingefügt werden kann, muss sie mit dem Explore verknüpft sein, in dem always_join verwendet wird. Das funktioniert beispielsweise nicht:

explore: event {
  always_join: [member]
}

Hier wurde die Ansicht member nicht mit event verknüpft und ist daher nicht für die Verwendung in always_join verfügbar.

Wichtige Punkte

Geschäftslogik nach Möglichkeit nicht in Joins anwenden

In Looker wird für Joins nach Möglichkeit LEFT JOIN verwendet. In den vorherigen Beispielen wird LEFT JOIN vermieden, damit die Geschäftslogik innerhalb des Joins angewendet werden kann. In einem der Beispiele haben wir ein Explore erstellt, das nur die Ereignisse enthält, die mit Mitgliedern verknüpft sind:

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

Die bevorzugte Methode, dies in Looker auszuführen, ist die Verwendung von LEFT JOIN, um Ereignisdaten und Mitgliedsdaten einfach zusammenzuführen:

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

Anschließend können Sie eine Dimension erstellen, die Sie auf „Ja“ oder „Nein“ setzen können, um nur Mitgliederevents zu berücksichtigen:

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

So können Nutzer alle Ereignisse oder nur Mitgliederereignisse ansehen. Sie haben Nutzer nicht gezwungen, sich nur Mitgliederereignisse über den Join anzusehen.

Wenn ein Explore always_join enthält, wird der Standardwert von full_suggestions zu yes geändert.

Wenn ein Explore den Parameter always_join enthält, wird der Standardwert von full_suggestions zu yes geändert. Dadurch wird die Abfrage für Vorschläge mit der Explore-Logik ausgeführt. Das bedeutet, dass always_join angewendet wird, um die zurückgegebenen Vorschläge einzugrenzen. Die Liste der Vorschläge wird also auf die Daten beschränkt, auf die der Nutzer Zugriff haben soll.

Wenn Sie full_suggestions manuell auf no festlegen, wird die Abfrage für Filtervorschläge nicht ausgeführt.