Nutzung
explore: view_name_1 {
join: view_name_2 { ... }
join: view_name_3 {
required_joins: [view_name_2, ...]
}
}
|
Hierarchie
required_joins |
Standardwert
Keine
Akzeptiert
Eckige Klammern mit einer durch Kommas getrennten Liste von Joins für diesen Explore-Bereich
Besondere Regeln
Eine Ansicht muss mit einem Explore verknüpft werden, bevor sie in required_joins referenziert werden kann.
|
Definition
Mit required_joins wird erzwungen, dass ein oder mehrere joins in den von Looker generierten SQL-Code aufgenommen werden, auch wenn der Nutzer kein Feld aus dieser verknüpften Ansicht ausgewählt hat. Dieses Verhalten wird ausgelöst, wenn der Nutzer ein Feld aus einer zugehörigen Ansicht auswählt, die Sie angeben. Mehrere Joins können mit einer durch Kommas getrennten Liste wie [join_name_a, join_name_b, ...] 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. Im Syntaxdiagrammbeispiel oben auf dieser Seite:
- Wenn ein Nutzer nur ein Feld aus
view_name_2auswählt, ist das die einzige Ansicht, die mit dem Explore verknüpft wird. - Wenn ein Nutzer ein Feld aus
view_name_3auswählt, wird durch den Parameterrequired_joinsdieses Joinsview_name_2in den Explore eingebunden.
Die primären Anwendungsfälle für required_joins:
Alter Syntaxstil mit sql_on
sql_on benötigt required_joins nicht, wenn es mit der ${view_name.looker_dimension_name}-Syntax verwendet wird. Bei einigen älteren Modellen wird jedoch noch die view_name.native_column_name-Syntax verwendet. Beispiel:
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]
}
}
In diesem Beispiel muss die Ansicht order immer mit der Ansicht customer verknüpft werden, wenn ein Nutzer ein Feld aus customer auswählt, damit die richtige Join-Beziehung beibehalten wird. Wenn Sie vergessen, diese Abfragen zu verlangen, können sie trotzdem funktionieren, wenn der Nutzer Felder aus allen erforderlichen Ansichten auswählt. Bei anderen Abfragen kann es jedoch aufgrund des fehlerhaften Joins zu fehlerhaften Daten kommen, ohne dass dies gemeldet wird.
Anstatt required_joins zu verwenden, sollten Sie das Modell so anpassen, dass die ${view_name.looker_dimension_name}-Syntax verwendet wird.
Sie müssen oder möchten rohen SQL-Code schreiben.
Es gibt einige Fälle, in denen Sie die ${view_name.looker_dimension_name}-Syntax nicht mit sql_on verwenden können oder möchten. In der Regel möchten Sie die Rohwerte in Ihrer Datenbank verwenden und alle Umwandlungen oder anderen Manipulationen vermeiden, die mit der ${view_name.looker_dimension_name}-Syntax auftreten. Hier ein Beispiel für die Verwendung:
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
}
}
In diesem Beispiel basiert der pre_sign_up_events-Join auf Datumsangaben aus user. Daher ist es wichtig, dass user mit required_joins verknüpft wird.
Anstatt required_joins zu verwenden, um die Umwandlung mit Zeit- oder Datumsfeldern zu vermeiden, sollten Sie den Typ date_raw verwenden und auf required_joins verzichten.
Häufige Herausforderungen
Eine Ansicht muss mit einem Explore verknüpft werden, bevor sie in required_joins referenziert werden kann.
Damit Sie eine Ansicht in required_joins einfügen können, muss sie mit dem explore verknüpft sein, in dem required_joins verwendet wird. Das funktioniert beispielsweise nicht:
explore: order_items {
join: customer {
sql_on: order.customer_id = customer.id ;;
required_joins: [order]
}
}
Hier wurde order nicht mit order_items zusammengeführt und ist daher nicht für die Verwendung in required_joins verfügbar.