JumboCode / TUTV

JumboCode project for TUTV, currently led by Frank Ma. Led by Deepanshu Utkarsh 2019 - 2020.
4 stars 0 forks source link

Return number of available equipment items from equipment_item endpoint #124

Open Frama-99 opened 3 years ago

Frama-99 commented 3 years ago

Currently, the number remaining displayed in the frontend is the total number of instances of a given item. We want this number to actually reflect the number of available instances given the request interval. image

I can think of two ways to go about this, and neither 100% works :'(

Approach 1

Given a new request interval, compare it against the request intervals of all existing requests (there are ways to optimize this if we store existing requests in sorted order). For each existing request that overlaps with the new request, for each item of equipment in that request, keep track of how many instances are occupied. Finally, when returning the list of equipment items, compute the number of available instances by subtracting the # occupied instances from the # total instances.

With this approach, computing the # instances available for all items would take O(number of overlapping requests * avg number of items per request).

There is an edge case that isn't considered by this algorithm. Say we have the following scenario:

(____Existing Req A____)      (____Existing Req B____)
                (____New Request C____)

If we have two instances of an item contained in all three requests, the above algorithm would incorrectly conclude that no instances are available, whereas there should be one available.

Approach 2

We can keep a list of occupied times for each item of equipment. In this design, checking the number of available instances of an equipment item requires checking this list against the new request interval.

With this approach, computing the # instances available for all items would take O(number of equipment items * avg number of existing requests per item). I think this might be slower than approach 1 (?)

Note that for the purposes of this feature, it does not suffice to store occupied times at the instance level. This is because requests that are submitted but not yet checked out do not have specific instances assigned. The only information they contain is the number of requested instances for an item, which is why we have to rely on a list of occupied times on the item rather than the instance.

We also still run into the same edge case that approach 1 encounters.

Frama-99 commented 1 year ago

@pmelga01 let me know if you can think of something to address that edge case... I've exhausted my brain cells for today