Skip to content

LengthUnit.polyfield_config

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

At a glance

  • Model: LengthUnit (MongoDB)
  • App: reference
  • Table/Collection: unit
  • Type: StringField
  • Column/Key: polyfield_config
  • Nullable: yes

Purpose

What it is. polyfield_config is a short string on the unit naming the sector the Throws map should draw — in practice the implement the meeting is throwing, as the PolyField client named it. It selects the two numbers the plot needs and cannot guess: the radius of the throwing circle (or the javelin arc) and the angle of the sector.

Accepted values. The kit resolves the string case-insensitively (implementFor() in static/polyfield/polyfield-throws-map.js:132):

  • Discus — 1.25 m circle, 34.92° sector
  • Hammer — 1.0675 m circle, 34.92° sector
  • Shot — 1.0675 m circle, 34.92° sector
  • Javelin — 8 m arc, 29° sector

The event codes are understood too, so an unconfigured unit still draws correctly: DT → discus, HT → hammer, WT → hammer (weight throw uses the hammer circle), SP → shot, JT → javelin. Anything unrecognised, or an empty value, is drawn as a discus — a hammer circle is nearly the same size, so the error is small for the other circle implements and only the javelin arc looks obviously wrong.

How it reaches the page. comp/views.py:11237 puts the unit's value in the template namespace, falling back to discipline_group_code(event.event_code) when the unit has none. The template emits it as throwsMapConfig (unit_length_detail.html:716) and the Vue method passes it to the kit as config (:745), preferring the rendered value over unit.polyfield_config. The kit then maps it to IMPLEMENTS and draws the circle, the sector lines and the distance rings from it.

Why the fallback matters. polyfield_config is optional, and the map is not gated on it — it is gated on coordinates (has_polyfield_data). So a client that sends landings but never names the sector, or an older unit that predates the field, still gets a correctly shaped plot from the event code. The field is only needed when the event code would be ambiguous — most obviously a javelin thrown on a unit whose event code is generic, or a weight throw.

Where it is not. It is not a SQL column and it is not in the unit API payload: the unit serializers don't read or write it, so it cannot be set through the DR API. It lives on the mongo unit document and is carried with the measuring client's own data. Nothing else in the system reads it — results, scoring and the results array ignore it entirely.

Help text (shown in the admin)

Which sector the throws map draws for this unit, as named by the measuring client. Accepts:

  • 'Discus' - 1.25 m circle, 34.92 degree sector
  • 'Hammer' - 1.0675 m circle, 34.92 degree sector
  • 'Shot' - 1.0675 m circle, 34.92 degree sector
  • 'Javelin' - 8 m arc, 29 degree sector

The event codes DT, HT, WT, SP and JT are understood too (WT is drawn as a hammer). Anything else, or an empty value, is drawn as a discus. When the unit has no config at all the event code is used instead, so a throws event plots correctly without it.

Where is this field used?

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

  • comp/views.py — lines 11237
  • comp/templates/comp/unit_length_detail.html — lines 621, 716, 745
  • comp/tests/test_throws_map.py — lines 83, 129
  • reference/mongo/length.py — lines 142, 159

Where it is defined

  • reference/mongo/length.py, line 142

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