Timeline for How to prevent overlap booking on a calendar booking system
Current License: CC BY-SA 4.0
16 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 30, 2023 at 16:51 | answer | added | Munim | timeline score: 1 | |
| Mar 1, 2019 at 15:00 | history | tweeted | twitter.com/StackSoftEng/status/1101497510504353793 | ||
| Feb 28, 2019 at 13:02 | history | bumped | CommunityBot | This question has answers that may be good or bad; the system has marked it active so that they can be reviewed. | |
| Jan 29, 2019 at 23:17 | comment | added | smurf | I was rethinking to see if I can model this problem similar to hotel room allocation problem (instead of night but different time slow). Then to see if a new booking need to check availability, I can query all the related booking/reservation related to this request then according to relocatable status, trying to find a solution to fit this request (probably generate all scenario if I want to know how many options it could fit, space would be amount of bookings and rooms). Then this process will need to run 2 times, one at inquiry and one at actual booking to make sure no one race in first. | |
| Jan 29, 2019 at 20:30 | comment | added | Srinivas | Thinking out loud, Can we just do ROOM <-> START_TIME - END_TIME and before each booking look for entries from DB whether there exists an entry where start_time >= requested_start_time and start_time <=requested_end_time and additional checks like that.. | |
| Jan 29, 2019 at 12:18 | answer | added | Rikalous | timeline score: 2 | |
| Jan 28, 2019 at 20:31 | answer | added | Jon Raynor | timeline score: 0 | |
| Jan 28, 2019 at 19:24 | comment | added | smurf | Let us continue this discussion in chat. | |
| Jan 28, 2019 at 19:03 | comment | added | smurf | To make this feature complete, it would handle the flow you proposed, that 2 user can enter the flow at the same time, with two temporary reservation, this correctly prevent the 3rd user, to enter the flow since these reservation would show at the point of 3rd look up. At the time of submit, the two user if have different in time of submission, one will be rejected at that time. However, if they again submit at the same time, conflict would happen, then I would need a "confirmation system" to detect and clean up the conflict by sending email out saying the booking is conflicted and rejected? | |
| Jan 28, 2019 at 18:36 | comment | added | Berin Loritsch | You are probably overthinking this. The load on the system can't be that high due to the physical constraints of the problem. You have a limited resource: time on x conference rooms. The number of opportunities to reserve the room will be limited. The likelihood that 2 people are attempting to reserve the same conference room at the same time is low, but not zero. It is proportional to the ratio of users to conference room time slots though. More people with fewer time slots means a higher likelihood of conflict for the resources that are left. | |
| Jan 28, 2019 at 18:30 | comment | added | smurf | Thank you for your explanation, for the "someone else" situation, when the user submit, then I have to read the booking system again to double check on the slot, then response accordingly correct? Will that "read" on database acceptable? Given every potential write would require a single read, or is it common? I am probably over thinking this stuff, but I am thinking about would this put stress on reading the system? | |
| Jan 28, 2019 at 18:24 | comment | added | Berin Loritsch | With temporary reservations, first one wins. Default time for meetings should be minimum of 30 minutes, although 60 minutes is probably more common. You will need some sort of UX. If on submit someone else has the temporary lease, you have to return the "Sorry it's reserved" message. With a multi-conference room set up, usually size and time are the most important thing. You can do a best match and have them both be winners, and send out an email confirmation with the real conference room number after you choose for them. | |
| Jan 28, 2019 at 18:18 | comment | added | smurf | I was thinking about the same thing, but the problem is with that, I definitely need some kind of UX to "reserve" on the time for some period of time (5min, 15min or something like that), but would that circle around the same problem? two user put the time reservation at the exact same time? I agree that in practice, this might not happen that often since each user might spend different time to finish the booking. But I am trying to understand hypothetically, if both user enter the flow at the same time and finish at the same time, then what happen, how to fail the other user correctly. | |
| Jan 28, 2019 at 18:12 | comment | added | Berin Loritsch | What about a simple "temporary reservation" object that has a temporary lease on the time. Once the reservation is cancelled or times out, the time is made available again. Otherwise that reservation is committed. | |
| Jan 28, 2019 at 18:10 | review | First posts | |||
| Jan 28, 2019 at 18:29 | |||||
| Jan 28, 2019 at 18:07 | history | asked | smurf | CC BY-SA 4.0 |