Booking model and resource

[ngjunsiang]

• Design Booking model & schema feat: Add VenueBooking and Venue models for booking management #393
• List API routes for booking resource
• Create API blueprint and routes for booking
• Implement booking resource

API routes

• POST /api/v1/bookings/
  {"user_id": UUID, "venue_id": CampusID, "description": str, "start_time": Time, "end_time": Time, "date": Date, "created_at": DateTime}: Uploads a booking request

• GET /api/v1/bookings/<booking_id>/ -> dict: Gets details of one booking by id

• DELETE /api/v1/bookings/<booking_id>/: Deletes an existing booking by id

• GET /api/v1/bookings/?user_id=&venue_id=&date= -> list[dict]: List bookings that meet criteria

• PATCH /api/v1/bookings/<booking_id>/ {"description": str}: Updates booking description.

[ngjunsiang]

App screenshots in #390 (comment)

[SavioNYJC]

Proposed schema:
Booking

• id (CampusID)
• user_id (str/int)
• description (str)
• created_at (str)

BookingSlot

• id (CampusID)
• booking_id (FK), (CampusID)
• venue (str)
• start_time (str)
• end_time (str)

@ngjunsiang

[ngjunsiang]

@SavioNYJC do we need separate Booking and BookingSlot? What if we simplify to VenueBooking (each booking is for one venue and one time range)?

We might not need the 1-to-many relation between Booking & BookingSlot if we sidestep the "one booking can have multiple slots" model and just have the user make multiple bookings. And we can improve the interface subsequently while keeping the same data model.

[SavioNYJC]

@ngjunsiang Hmm that's true.
Something like this would suffice right?
VenueBooking

• id (CampusID)
• user_id (str)
• venue (str)
• description (str)
• start_time (DateTime)
• end_time (DateTime)
• created_at (DateTime)

As for the routes:, I'm not quite sure how I should create them. Is it something along the lines of this?

• POST /bookings/
• GET /bookings/ (goes to the booking/managing bookings page)
• GET /bookings/<user_id> -> list[dict]
• GET /bookings/time (goes to 'book by time' page) -> list[str]
• GET /bookings/time/<time> -> list[str]
• GET /bookings/venue (goes to 'book by venue' page) -> list[str]
• GET /bookings/venue/<venue_type> -> list[str]
• GET /bookings/venue/<venue_type>/<venue_id> -> list[dict]

[ngjunsiang]

Something like this would suffice right?
VenueBooking

• id (CampusID)
• user_id (str)
• venue (str)
• description (str)
• start_time (DateTime)
• end_time (DateTime)
• created_at (DateTime)

Probably not a good idea to allow bookings across day boundaries. You might want to separate booking date and the start/end time

This time the venue is not just a timetable-venue label, it will be its own proper model with CampusID and other fields (e.g. seating capacity), so venue should use ID rather than label

[ngjunsiang]

As for the routes:, I'm not quite sure how I should create them. Is it something along the lines of this?

• POST /bookings/
• GET /bookings/ (goes to the booking/managing bookings page)
• GET /bookings/<user_id> -> list[dict]
• GET /bookings/time (goes to 'book by time' page) -> list[str]
• GET /bookings/time/<time> -> list[str]
• GET /bookings/venue (goes to 'book by venue' page) -> list[str]
• GET /bookings/venue/<venue_type> -> list[str]
• GET /bookings/venue/<venue_type>/<venue_id> -> list[dict]

You're thinking about the app routes, like what nyxchange-timetable would use. But this is designing for API routes only.

So we'll likely need routes for:

• create new booking
• get existing booking by ID
• delete existing booking by ID
• list bookings matching search criteria (by user ID, venue ID, date)
• update booking by ID (for simplicity we don't allow changing of venue/date/time for booking, only description. Change of date/time requires creating new booking)

[SavioNYJC]

venue is not just a timetable-venue label, it will be its own proper model with CampusID and other fields (e.g. seating capacity), so venue should use ID rather than label
Makes sense.

Booking

• id (CampusID)
• user_id (str)
• venue_id (CampusID)
• description (str)
• start_time (DateTime)
• end_time (DateTime)
• date (DateTime)
• created_at (DateTime)

Venue

• venue_name (str)
• other fields (TBC)

Will we settle the fields for the venue itself during a meeting?

[SavioNYJC]

You're thinking about the app routes, like what nyxchange-timetable would use. But this is designing for API routes only.

So we'll likely need routes for:

• create new booking
• get existing booking by ID
• delete existing booking by ID
• list bookings matching search criteria (by user ID, venue ID, date)
• update booking by ID (for simplicity we don't allow changing of venue/date/time for booking, only description. Change of date/time requires creating new booking)

• POST /api/v1/bookings/ {"user_id": UUID, "venue_id": CampusID, "description": str, "start_time": DateTime, "end_time": DateTime, "date": DateTime, "created_at": DateTime}: Uploads a booking request
• GET /api/v1/bookings/<booking_id> -> dict: Gets details of one booking by id
• DELETE /api/v1/bookings/<booking_id>: Deletes an existing booking by id
• GET /api/v1/bookings/?user_id=&venue_id=&date= -> list[dict]: List bookings that meet criteria
• PATCH /api/v1/bookings/<booking_id> {"description": str}: Updates booking description.

@ngjunsiang Are these fine for API routes? I'm unsure how to display query params when listing them out.

[ngjunsiang]

Booking

• id (CampusID)
• user_id (str)
• venue_id (CampusID)
• description (str)
• start_time (DateTime)
• end_time (DateTime)
• date (DateTime)
• created_at (DateTime)

Venue

• venue_name (str)
• other fields (TBC)

Will we settle the fields for the venue itself during a meeting?

Probably don't need a meeting, we can discuss over PR.

• we may have other kinds of bookings in future, so let's name it VenueBooking for now
• we will need separate Date and Time types; schema.Date already exists but I'll need to create schema.Time
• Venue inherits Model so will have id and created_at fields as well

Can go ahead and create a PR for this model first, I'll make a separate PR to add schema.Time

[ngjunsiang]

• POST /api/v1/bookings/ {"user_id": UUID, "venue_id": CampusID, "description": str, "start_time": DateTime, "end_time": DateTime, "date": DateTime, "created_at": DateTime}: Uploads a booking request
• GET /api/v1/bookings/<booking_id> -> dict: Gets details of one booking by id
• DELETE /api/v1/bookings/<booking_id>: Deletes an existing booking by id
• GET /api/v1/bookings/?user_id=&venue_id=&date= -> list[dict]: List bookings that meet criteria
• PATCH /api/v1/bookings/<booking_id> {"description": str}: Updates booking description.

Looks fine. Add a trailing slash after <booking_id>, i.e. <booking_id>/ for consistency with other routes