Created fact_bookings.#38
Conversation
…ke sure the attendance flags work.
harjeetkalsi
left a comment
harjeetkalsi
left a comment
There was a problem hiding this comment.
Great this looks good, almost there!
I think this would be a good candidate for a unit test with a few fake rows and expected outputs, just to lock in the behaviour. For example:
attended -> is_attended = true
cancelled -> is_cancelled = true
no_show -> is_no_show = true
possibly an unexpected or null status as well, depending on how we want to handle that case
One smaller point: I would also consider avoiding select * in the bookings CTE unless there is a reason to keep it broad, as being explicit can make schema changes easier to manage.
…r attendance flags.
| - {booking_id: 1, member_id: 101, class_id: 1001, booking_timestamp: '2025-01-10 09:00:00', attendance_status: 'attended', check_in_timestamp: '2025-01-10 09:55:00', cancellation_timestamp: null} | ||
| - {booking_id: 2, member_id: 102, class_id: 1002, booking_timestamp: '2025-01-11 10:00:00', attendance_status: 'cancelled', check_in_timestamp: null, cancellation_timestamp: '2025-01-10 15:00:00'} | ||
| - {booking_id: 3, member_id: 103, class_id: 1003, booking_timestamp: '2025-01-12 11:00:00', attendance_status: 'no_show', check_in_timestamp: null, cancellation_timestamp: null} | ||
|
|
There was a problem hiding this comment.
could you add one more test case where attendance_status is just 'null' to begin with, just to check it is handled correctly, otherwise this all looks good :)
3 participants
Made the sql and yml files for fact_bookings. Added a singular test too to make sure the attendance flags work.
Ticket: Here
All ran, built and tests passed on individual machine.