Skip to content

LengthTrial.polyfield

Field-level detail page. Use the search bar to jump straight to it.

At a glance

  • Model: LengthTrial (MongoDB)
  • App: reference
  • Table/Collection: ``
  • Type: EmbeddedDocumentField → embedded <class 'project.reference.mongo.length.PolyField'>
  • Column/Key: polyfield
  • Nullable: yes

Purpose

What it is. polyfield is an embedded PolyField document on one attempt (LengthTrial) in a throws or horizontal-jump unit. It holds the landing position the PolyField measuring client worked out for that attempt — rx across the sector, ry out along it, both in metres — and it is the only per-attempt data the Throws map draws. Without it the attempt is still a normal result; it just has no place on the diagram.

Where it comes from. The measuring client records an attempt and PATCHes it on its own, rather than re-sending the whole unit (a bare object writes one row on any verb, so POST or PUT work too):

PATCH /api/x/<year>/<country>/<slug>/event/<event_id>/<round>/<heat>/record/trials/ with {"bib": "55", "round": 3, "result": "6.87", "to_board": "0.12", "polyfield": {"rx": "-0.42", "ry": "7.31"}}

comp/api.py:1262 (_apply_single_trial) turns that body into the trial with embedded_from_dict, so polyfield is stored because the model declares the field — there is no per-field whitelist to keep in step. The attempt is matched on bib + round and replaced if present, otherwise appended, and a unit revision is written as for any other edit. The bulk recording payload ({"trials": [...]}) accepts polyfield on each entry in the same way.

Storage. rx and ry are DecimalField(precision=2, force_string=True), so they are saved as 2dp strings, e.g. "rx": "-1.37", "ry": "6.46", exactly as the client sent them. Nothing in the schema assumes an origin or a rotation: the numbers are stored verbatim and the drawing side interprets them.

Who reads it. comp/views.py:11241 sets has_polyfield_data for the event page, true only when at least one trial has both rx and ry; that flag decides whether the Throws map tab, its assets and its script are rendered at all. The template hands the unit's trials to the kit, which drops attempts without coordinates before drawing (unit_length_detail.html:739 filters on t.polyfield.rx/ry, and the kit's marksFrom() reads bib, round, result and polyfield). Fouls (result = x) are drawn as crosses from their bib and round alone, so they do not need a landing point.

What it does not affect. Results, places and points are computed from result; polyfield never takes part in scoring or in the results array. An attempt with coordinates and an attempt without are identical to the timing/results machinery — the coordinate is extra, not a replacement for the distance.

Absent when. Hand-recorded attempts (a recorder typing distances on the Trials tab) and fouls have no polyfield; anything imported without measurement data likewise. Those attempts appear in Results and on the Trials tab and are simply not plotted, which is why an event with no measured attempts never shows the map tab at all.

Help text (shown in the admin)

Landing position measured by PolyField, when the measuring client supplied one. Present on the attempts the client measured; absent on hand-recorded attempts and on fouls, which carry a result of 'x' and no landing point. This is what the throws map plots, so a unit only shows that tab once at least one trial has both rx and ry — attempts without it still count in the results and appear on the Trials tab.

Where is this field used?

References found by scanning the codebase for `polyfield` (as a whole word):

  • drapi/renderers.py — lines 25
  • drapi/tests/test_natural_key_api.py — lines 1124, 1140, 1147, 1148, 1151, 1152, 1249
  • drapi/tests/test_urls.py — lines 260, 273, 286, 287, 297, 298
  • comp/views.py — lines 11242
  • comp/templates/comp/unit_length_detail.html — lines 7, 286, 357, 621, 624, 655, 739, 783
  • comp/tests/test_throws_map.py — lines 87, 112, 113, 114, 133, 136, 144, 145…
  • static/polyfield/polyfield-throws-map.js — lines 3, 8, 17, 20, 22, 23, 25, 38…
  • reference/mongo/length.py — lines 78
  • reference/tests/test_mongo_utils.py — lines 23, 28, 30, 31, 32

Where it is defined

  • reference/mongo/length.py, line 78

Generated by docs_models management command — extend the Purpose section by hand if you need to write more detail for this field.