What actually gets written: the Booking model and its relations

Chapter IV

What actually gets written: the Booking model and its relations

The createBooking() call from the trace writes one Booking row, but that row is deliberately thin: its references and seatsReferences relations stay empty at creation time and are filled in later by separate writes once EventManager talks to the external calendar or video provider. This module reads the Booking, BookingReference, Attendee, and BookingSeat models in packages/prisma/schema.prisma to show exactly which fields createBooking() populates immediately and which related tables are populated afterward, and why the application code (createBooking, EventManager, RegularBookingService) is written to match the shape of those Prisma models rather than the reverse.

walkthrough

buildNewBookingData: turning request data into a Prisma.BookingCreateInput

packages/features/bookings/lib/handleNewBooking/createBooking.ts · lines 168–202

lines 181–182

Before assembling the write, getAttendeesData(evt) and getEventTypeRel(eventType.id) pre-shape two pieces of the incoming request into the exact structures Prisma's relation API expects, so the object literal below can just reference them.

line 184

uid is set as a bare scalar — this is the value the caller generated and passed in, landing directly on the Booking.uid @unique column.

lines 188–189

startTime/endTime are normalized to UTC with dayjs.utc(...).toDate() before being written, matching the plain DateTime columns on Booking that carry no timezone of their own.

line 192

status is decided right here, not left to the schema's @default(ACCEPTED) — a ternary on eventType.isConfirmedByDefault picks BookingStatus.ACCEPTED or BookingStatus.PENDING, which later determines whether RegularBookingService immediately syncs to the calendar or queues a confirmation webhook instead.

line 195

eventType: eventTypeRel writes the pre-built { connect: { id: eventTypeId } } object rather than an eventTypeId scalar — Prisma's nested-write API models relations as connect/create instructions, not raw foreign keys, so getEventTypeRel exists purely to produce that shape.

lines 198–201

attendees: { createMany: { data: attendeesData } } } is a nested write: Prisma creates one Attendee row per entry in attendeesData inside the same tx.booking.create call, and stamps each with this booking's bookingId — no separate insert is needed for the fan-out to happen.

168function buildNewBookingData(params: CreateBookingParams) {169  const {170    uid,171    evt,172    reqBody,173    eventType,174    input,175    originalRescheduledBooking,176    rescheduledBy,177    creationSource,178    tracking,179  } = params;180181  const attendeesData = getAttendeesData(evt);182  const eventTypeRel = getEventTypeRel(eventType.id);183  const newBookingData: Prisma.BookingCreateInput = {184    uid,185    userPrimaryEmail: evt.organizer.email,186    responses: input.responses === null || evt.seatsPerTimeSlot ? Prisma.JsonNull : input.responses,187    title: evt.title,188    startTime: dayjs.utc(evt.startTime).toDate(),189    endTime: dayjs.utc(evt.endTime).toDate(),190    description: evt.seatsPerTimeSlot ? null : evt.additionalNotes,191    customInputs: isPrismaObjOrUndefined(evt.customInputs),192    status: eventType.isConfirmedByDefault ? BookingStatus.ACCEPTED : BookingStatus.PENDING,193    oneTimePassword: evt.oneTimePassword,194    location: evt.location,195    eventType: eventTypeRel,196    smsReminderNumber: input.smsReminderNumber,197    metadata: reqBody.metadata,198    attendees: {199      createMany: {200        data: attendeesData,201      },202    },

step 1 of 6

801model BookingReference {802  id                         Int      @id @default(autoincrement())803  /// @zod.string.min(1)804  type                       String805  /// @zod.string.min(1)806  uid                        String807  meetingId                  String?808  thirdPartyRecurringEventId String?809  meetingPassword            String?810  meetingUrl                 String?811  booking                    Booking? @relation(fields: [bookingId], references: [id], onDelete: Cascade)812  bookingId                  Int?813  externalCalendarId         String?814  deleted                    Boolean?815 816  credential             Credential?           @relation(fields: [credentialId], references: [id], onDelete: SetNull)817  credentialId           Int?818  delegationCredential   DelegationCredential? @relation(fields: [delegationCredentialId], references: [id], onDelete: SetNull)819  delegationCredentialId String?820 821  @@index([bookingId])822  @@index([type])823  @@index([uid])824}

packages/prisma/schema.prisma · lines 801–824

Figure I · type (e.g. "google_calendar" or "daily_video"), uid, meetingId, and meetingUrl are the external provider's own identifiers for the calendar or video event; bookingId is the foreign key tying that identity back to one Booking. This is the table EventManager and later webhook code query to answer "which Google Calendar event / Daily.co room belongs to this booking" without ever re-deriving it from scratch.

Why

Application code is shaped by the relation, not the other way around — Look at the object EventManager.create() builds for each synced calendar/video result: type, uid, thirdPartyRecurringEventId, meetingId, meetingPassword, meetingUrl, externalCalendarId. That field list is not a coincidence — it is EventManager constructing exactly the shape of a BookingReference row, field for field, because that model's columns in packages/prisma/schema.prisma are the contract the eventual write has to satisfy. This is schema-first modeling: the Prisma model defines the shape, and code that produces or consumes that data (EventManager, createBooking, RegularBookingService) is written to match it, rather than the schema being reverse-engineered from whatever the app happens to produce.

packages/features/bookings/lib/EventManager.ts · referencesToCreate :388–410packages/prisma/schema.prisma · BookingReference :801–824

2444  try {2445    if (!isDryRun) {2446      await deps.prismaClient.booking.update({2447        where: {2448          uid: booking.uid,2449        },2450        data: {2451          location: evt.location,2452          metadata: { ...(typeof booking.metadata === "object" && booking.metadata), ...metadata },2453          references: {2454            createMany: {2455              data: referencesToCreate,2456            },2457          },2458        },2459      });2460    }

packages/features/bookings/lib/service/RegularBookingService.ts · lines 2444–2460

Figure II · By the time this runs, createBooking()'s transaction already committed the Booking and Attendee rows — booking.uid here is the uid from that earlier write. RegularBookingService calls eventManager.create(evt, ...) in between (not shown in this excerpt), collects its referencesToCreate array, and only now issues a second deps.prismaClient.booking.update whose nested references: { createMany } writes the BookingReference rows. The booking's identity in your database and its identity in the external calendar are deliberately written in two separate steps, because the second one depends on a network call that can fail independently of the first.