So that the server doesn't accumulate database records that are useless and eventually crash
Discussion
There is currently a start date associated with each commons. In this issue we are just adding an end date
for the game. We'll use that end date in many ways in future issues (see "Future Issues" below), but in this issue we are just adding it.
This PR may be useful as a reference; it was not merged into the main code base yet, but outlines what needs to be done:
Note: don't just blindly copy/paste code from this; some of it is relevant, and some of it may not be. But it can be a useful reference.
Future Issues
Once this issue is done, it opens up the possibility of these:
For the automatic jobs that manipulate cow health, milk the cows, etc. we should restrict which commons these are done on to only the commons that have games in progress. There is no reason to milk cows, update health, produce instructor reports etc. for a game that's already over. It's important that these activities STOP at some point, or else we'll be filling up the database with useless rows indefinitely. That's how you crash a server.
A clean start/end date will likely make future graphs and visualizations easier to make.
We may want to restrict users from joining a commons before the game start date so that the instructor can set things up in advance, but students all start at the same time.
Acceptance Criteria
[ ] Add lastday date. (this is more clear than end date, since it indicates that the game ends at 11:59:59 on that day). Needs to be added to entity in backend, POST and PUT endpoints in backend, form in frontend, and adjusted on Create and Update pages.
[ ] Add a function to the Commons entity (and tests for it) called gameInProgress() that returns true if today's date is >= start date, and <= end date. This could be it's own PR, with tests. Note that mocking "today's date" is possible; tricky, but possible.
Acceptance Criteria for Future Issues:
[ ] Add logic to the backends of various jobs that operate on all commons (MilkTheCows, UpdateCowHealth, InstructorReports) where it iterates over the commons. Skip over commons where gameInProgress() returns false. You can find some code for this in a PR that was not merged from S23, here:
[ ] If instructor requests a job be run on a specific commons, it should run even if the game is not in progress.
User Story
Discussion
There is currently a start date associated with each commons. In this issue we are just adding an end date for the game. We'll use that end date in many ways in future issues (see "Future Issues" below), but in this issue we are just adding it.
This PR may be useful as a reference; it was not merged into the main code base yet, but outlines what needs to be done:
Note: don't just blindly copy/paste code from this; some of it is relevant, and some of it may not be. But it can be a useful reference.
Future Issues
Once this issue is done, it opens up the possibility of these:
For the automatic jobs that manipulate cow health, milk the cows, etc. we should restrict which commons these are done on to only the commons that have games in progress. There is no reason to milk cows, update health, produce instructor reports etc. for a game that's already over. It's important that these activities STOP at some point, or else we'll be filling up the database with useless rows indefinitely. That's how you crash a server.
A clean start/end date will likely make future graphs and visualizations easier to make.
We may want to restrict users from joining a commons before the game start date so that the instructor can set things up in advance, but students all start at the same time.
Acceptance Criteria
Acceptance Criteria for Future Issues: