Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Return number of available equipment items from equipment_item endpoint #124

Open
Frama-99 opened this issue Dec 2, 2020 · 1 comment
Open
Assignees
Labels
enhancement New feature or request technical Needs specific technical knowledge

Comments

@Frama-99
Copy link
Collaborator

Frama-99 commented Dec 2, 2020

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 Frama-99 added enhancement New feature or request technical Needs specific technical knowledge labels Dec 2, 2020
@Frama-99 Frama-99 changed the title Consider changing method of checking equipment item availability in backend Update method of checking equipment item availability in backend Dec 22, 2022
@Frama-99 Frama-99 changed the title Update method of checking equipment item availability in backend Return number of available equipment items from equipment_item endpoint Dec 22, 2022
@Frama-99
Copy link
Collaborator Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request technical Needs specific technical knowledge
Projects
None yet
Development

No branches or pull requests

2 participants