When creating new order, it does not follow running index.

[HongRay]

Steps to reproduce:

1. Create 2 orders.
2. Delete order index 2.
3. Create new order.

Expected: New order will be indexed 2 instead of 3.

Actual: New order index is 3 instead of 2.

[nus-pe-bot]

Team's Response

Intended. Our team feels that order id should be unique and should not repeat even though past orders have been completed. This will make tracking of orders less confusing. Hence, we chose to not follow running index to ensure uniqueness of each order ID.

Items for the Tester to Verify

:question: Issue response

Team chose [response.Rejected]

• [x] I disagree

Reason for disagreement: Even after re-launching the application, the orders still produced a unique ID. The orders should not be of a unique ID indefinitely for the following reasons:

1. Integer Overflow: If the IDs are assigned sequentially and the underlying data type has a maximum limit (like an integer in many programming languages), there is a risk of an integer overflow. This occurs when the number exceeds the maximum value that can be stored, which can lead to errors or unexpected behaviour.
2. Performance Issues: As the range of unique IDs increases, the time complexity to check for uniqueness or to index these IDs can also increase. This can lead to slower performance, especially with large datasets where quick access to data becomes critical.
3. At the end of the day, the user might want to reset the order ID to check how many orders are there for a single day of work, which could the industry's standards of tracking daily sales.

Implementing a simple reset ID command could solve the problem.

Additionally, this should be specified in the UG instead. However, if this is an intended outcome of the developers, due to hindsight, I believe that this would be a Feature Flaw.

---