Any models can be accessed via their respective endpoints. To filter them, you can use a request query parameter with the key name and your filter. The filter should be accepted by MongoDB, our back-end database.
These are the "building blocks" for our main schemas. Unlike the main schemas, they do not have their own collection in our database, but are instead incorporated into parent documents.
These 7 models are our main schemas and can be interacted with through their respective endpoints.
If the ref<T> generic type is used, it means that the field can be populated to its respective model via the expand query parameter. For performance reasons, this should only be done if the data is actually needed.
Judge
A judge has at least one JudgeRecord. This model should be used for performant judge searching by name. It is available at /judges.
An entry is comprised of one or more competitors. They are restricted to one event, but their tournament information can span multiple seasons and circuits. Consequently, we recommend filtering down to specific seasons and/or circuits via the request's query parameters. It is available at /entries.
interfaceEntry {// Metadata _id:string; codes:string[]; competitors:ref<Competitor>[]; schools:School[]; statistics?:Statistics; // Computed, Expandable// Can be used as filter options event:Event; circuits:Circuit[]; seasons:number[];// Results tournaments:ref<TournamentResult>[];}
Tournament Result
A tournament result is an entry's performance data at a given Tournament. It is available at /tournament-results.
A competitor is an individual. They have at least 1 associated Entry, but can have multiple (including across various events). This model should be used for performant debater searching by name, or to find out all activity of a specific debater. It is available at /competitors.