Source material:
...
Store
rounds
List as JSON in a single database column.This would require searching for the correct round based on start/end dates in memory
Evaluations object can be cleanly retrieved using query on single table
Separate Table For Rounds (primary key is evaluationId , ID) index on roundStart and roundEnd
Allows us to pull out one specific limit
Separate queries
query to retrieve list of all rounds for that evaluation,
On REST API GET, we care about all rounds
query to retrieve list single evaluation id,
On challenge submissions during the submission limit enforcement, we only care about the specific round whose start/end interval encapsulate the current time
query to pull from the Evaluations table
Limits are enforced in Java code so we can store the them as JSON
Question: should ID be created by the id-generator? or just index in rounds list?
generated unique ID makes it easy to perform updates on evaluations
with current API setup a list of round are submitted, making this pointless
index in round list as ID
this allows easier tagging of submission
updating rounds involves row deletion and addition if added
hash metdata to avoid pointless delete/add?
If we use roundStart, roundEnd to identify the round config.
any change to start,roundend would mean an insertion/deletion
evaluationId(BIGINT)(Foreign Key to Evaluations Table) | ID(BIGINT) | roundStart(TIMESTAMP) | roundEnd(TIMESTAMP) | Limits(JSON) | ||
---|---|---|---|---|---|---|
123 | 1 |
|
|
| ||
123 | 2 |
|
| … | ||
456 | 1 |
|
| … | ||
789 | 1 |
|
| … |
Evaluation_maintenance table
Records maintenance windows for each evaluation.
evaluationId(BIGINT)(Foreign Key to Evaluations Table) | startDate(TIMESTAMP) | endDate(TIMESTAMP) |
---|---|---|
123 |
|
|
456 |
|
|
Submission JDOSUBMISSION table
Add EVALUATION_ROUND, which is the round number during which it was submitted. This will be replicated into Submission Views.
...