DataBull Search
dating_platform/reservations.view.lookml 18 dims1 measure 3 warnings Repo files

LookML view · dating-platform

The bookings view: partner date bookings with a drill set into missing views

At a glance

Does
Reads one row per booking: offer and version, promo, subscription, quantity, price_paid, status, surprise and free-offer flags, and converted. One measure: count.Trust: Source-defined
Why
Tracks bookings of partner date offers, likely date experiences sold to members, and whether each booking converted.Trust: Inferred
Breaks
3 warnings. Top: one_to_one is set as a join type
Grain
One row per booking. id is the primary key, but version and offer_version suggest bookings change over time.Trust: Inferred
Source
dating_platform/reservations.view.lookml 100 lines
Source: reservations.view.lookml L1-10
dating_platform/reservations.view.lookmlL1-10
- view: bookings  fields:  - dimension: id    primary_key: true    type: int    sql: ${TABLE}.id  - dimension: converted    type: yesno    sql: ${TABLE}.converted  - dimension: couple_id    type: int    hidden: true    sql: ${TABLE}.couple_id

dating-platform, reservations.view.lookml, lines 1-10

Shape

Trust: Source-defined

Every field as declared, with the dashboard tiles that read it. Computed from the source; nothing here is edited.

Table: defaults to bookings (no sql_table_name).

Dimensions 18
NameTypeSQLUsed byTags
idL3int${TABLE}.id-primary key
convertedL7yesno${TABLE}.converted-
couple_idL10int${TABLE}.couple_id-hidden
createdtime, date, week, monthL14time group${TABLE}.created_at-
datebook_idL22int${TABLE}.datebook_id-hidden
is_free_offerL26yesno${TABLE}.is_free_offer-
last_updated_by_idL29int${TABLE}.last_updated_by_id-
offer_idL32int${TABLE}.offer_id-hidden
offer_versionL36int${TABLE}.offer_version-
price_paidL39int${TABLE}.price_paid-
promo_idL42int${TABLE}.promo_id-hidden
quantityL46int${TABLE}.quantity-
status_idL49int${TABLE}.status_id-
subscription_idL52int${TABLE}.subscription_id-hidden
surpriseL56yesno${TABLE}.surprise-
updatedtime, date, week, monthL59time group${TABLE}.updated_at-
user_idL67int${TABLE}.user_id-hidden
versionL71int${TABLE}.version-

Measures 1
NameTypeSQLUsed byTags
countL74countCOUNT(*) of rows-

Relationships

Trust: Source-defined

No joins, no upstream views and no dashboard tiles reference this view. It is an island in the model.

Relationships of bookings
Relationships of bookings. Text version follows the diagram.This viewUsed by: explores, views, dashboardsbase view bookings explore in partners
  • This Block
Text version
  • bookings is the base view of bookings: base view

Worth noticing

No table is named

Trust: Source-defined

The view has no sql_table_name or derived table, so Looker reads a table called bookings on the partners connection.

Source: reservations.view.lookml L1-6
dating_platform/reservations.view.lookmlL1-6
- view: bookings  fields:  - dimension: id    primary_key: true    type: int    sql: ${TABLE}.id  - dimension: converted    type: yesno    sql: ${TABLE}.converted

dating-platform, reservations.view.lookml, lines 1-6

Explored in the partners model

Trust: Source-defined

partners.model.lookml joins users on user_id and offers on offer_id. The offers view in deals.view.lookml adds price and non_member_price.

Source: partners.model.lookml L5-12
dating_platform/partners.model.lookmlL5-12
- scoping: true- include: '*.view.lookml'- include: '*.dashboard.lookml'- explore: bookings  view: bookings  joins:  - join: users    sql_foreign_key: user_id  - join: offers    sql_foreign_key: offer_id    join_type: one_to_one

dating-platform, partners.model.lookml, lines 5-12

What can change the answer 3

Caution: one_to_one is set as a join type

Trust: Source-defined

The offers join sets join_type: one_to_one. Join type takes values such as left_outer; one_to_one is a relationship value, so the relationship is still undeclared.

What goes wrong: The intent that each booking has one offer is never applied, and Looker falls back to its defaults.

Read the guide: Join fanout

Source: partners.model.lookml L10-12
dating_platform/partners.model.lookmlL10-12
  joins:  - join: users    sql_foreign_key: user_id  - join: offers    sql_foreign_key: offer_id    join_type: one_to_one

dating-platform, partners.model.lookml, lines 10-12

Caution: price_paid is an integer with no unit

Trust: Missing

price_paid is type: int. Whether it holds cents or whole currency units is not stated, and no measure sums it.

What goes wrong: Booking revenue built from it can be off by a factor of 100.

Source: reservations.view.lookml L39-41
dating_platform/reservations.view.lookmlL39-41
  - dimension: offer_version    type: int    sql: ${TABLE}.offer_version  - dimension: price_paid    type: int    sql: ${TABLE}.price_paid  - dimension: promo_id    type: int    hidden: true

dating-platform, reservations.view.lookml, lines 39-41

Note: The drill set points at 11 missing views

Trust: Source-defined

The detail set lists fields from partners_connection, promos, datebooks, reviews and seven other views that are not in the repo.

Read the guide: Missing tables and stale references

Source: reservations.view.lookml L78-100
dating_platform/reservations.view.lookmlL78-100
    type: count    detail: detail*  sets:    detail:    - id    - partners_connection.unregistered_partner_last_name    - partners_connection.unregistered_partner_name    - partners_connection.id    - offers.id    - users.id    - users.first_name    - users.last_name    - promos.name    - promos.id    - subscriptions.name    - subscriptions.id    - datebooks.internal_name    - datebooks.display_name    - datebooks.id    - booking_adjustments.count    - booking_details.count    - booking_versions.count    - charge_responses_bookings.count    - reservations.count    - reviews.count    - temp_reservations.count

dating-platform, reservations.view.lookml, lines 78-100

Related

Guides built on this file

Guide Preventing join fanout by declaring every relationship Why sums and counts grow after a join, how to check any model for fanout, and the SQL and LookML that keep totals honest, from real join mistakes. Best practicesRevenue Guide Catching missing tables and stale references before a dashboard breaks Models can name tables, fields and explores that do not exist, and nothing fails until a chart runs. Real examples, and how to check yours before release. Best practices

Related source files

Source file subscriptions Reads one row per subscription from public.subscriptions: status, auto_renew, trial_days, renewal period an... view3 warnings Source file enterprise Declares six explores on project_connection: churn, transactions, messages, propositions, date_ideas and te... model4 warnings

Source model

Source model Inside a dating platform LookML project: sessions, revenue, subscriptions and messaging Product, revenue and customer analytics 17 views20 joins