Object: Declare variables and instantiate them and create columns for the SQL DB in order to have raw data to be able to sort specific users based on account growth and give them a rating.
Collectable: Used as an abstract class( a class which isn't instantiated on its own) to set key types and variables for the performance, here we also initialize the specific variables.
Itterator: The iterator manages the object through an interface for the performance object and as an iterator the function of the file is to The class includes methods to get the list size, update the key type for sorting purposes, and perform a merge sort on the list. This is to sort by the key value of account value that was set in the collectable and make the full dataset be active and work.
Working Feature
USE OF SORTING IN THE ITTERATOR
SQL IMPLEMENTATION
POSTMAN REQUESTS
FRONTEND FETCH AND WORKING TABLE!
ERRORS THAT WERE FACED!
POM.XML; with working on different versions, since everyones codebase was constantly changing using wrong headers and imports often left dependencies to fail and build not working in the front-end, however this was fixed through better communication and better branch management.
Being able to have test data: every time we tried to make a postman request to post new data and later on make a get request so that it sorted the list by a specified attribute, we would get some sort of error, such as a 405 Not Allowed error or even an Internal Server Error. Later on, however, we found that this was because we were missing PostMapping in our API controller for the performance leaderboard, so we added that along with a new endpoint so that it could create new users. Now we are able to add users to the list along with their other attributes.
(used the wrong endpoint and format when adding the data)
Creating a leaderboard for the users performance based on rating