OpenTrack data models (staff reference)
Automatically-generated reference to OpenTrack's data models — both engines:
- SQL — the Django models (
reference_*,comp_*relational tables), and - MongoDB — the mongoengine documents (competition, entries, units, scores…).
Use the search bar to jump straight to a field (e.g. restrict_team_declaration_to_club) or a model (e.g. Competition). Each model page lists, per field: engine type, column/key, null/PK/default, expanded choices, relations to other models, and the human help_text (the same text shown as hints in OpenTrack admin/entry forms).
Fields whose help text isn't written yet show — in the Notes column — add a help_text on the model and it'll appear next time the command runs.
Regenerating: from the OpenTrack code repo run
python manage.py docs_models --app reference --out /path/to/ot-staff-docs/docs
(use --all to document every app). Pages are written under docs/reference/.
PolyField fields (throws)
The Throws map on a field event is driven by one embedded document on the trial and two fields on the unit:
| Where | Field | Holds |
|---|---|---|
| Trial — LengthTrial | polyfield → rx, ry |
The measured landing position, in metres, in the sector's rotated axes, exactly as the measuring client supplied it. Hand-recorded attempts have no polyfield, and fouls carry no coordinates. |
| Unit — LengthUnit | polyfield_config |
Sector configuration name from the measuring client — Discus, Hammer, Shot, Javelin (the event codes DT, HT, WT, SP, JT also match). Selects the circle radius and sector angle; unknown or blank falls back to a discus-sized circle with the standard 34.92° sector. |
| Unit — LengthUnit | polyfield_geometry |
Geometry as supplied by the client, stored as-is. The current plot does not read it: each implement's geometry is built into the kit. |
Attempts arrive one at a time on .../record/trials/ with polyfield: {"rx": ..., "ry": ...} (see the Units API docs on docs.opentrack.run). The map tab is only rendered once at least one trial has both coordinates (has_polyfield_data in project/comp/views.py), and when polyfield_config is unset the event code is used instead — so a throws event plots correctly with no unit-level configuration at all.
Neither unit-level field is part of the unit API payload: the unit serializers neither return nor accept them, so they only ever arrive with the measuring client's own data.