TURFI

Documentation Search

Search only within Turfi documentation pages.

Player Registrations

Player registration registry contract, standalone grid behavior, and import/write rules.

Entity: Player Registrations

1. Overview

Import-linked registration table connecting players to teams, clubs, seasons, competitions, and roster metadata.
Belongs to a player and team.
May also carry club, organization, season, and competition context.
Supports roster-derived metadata such as jersey number and registration type.
May retain import provenance through source_roster_entry_id into team_roster_entries.
Visible at /admin/data/registries/player-registrations.
Primary operator surfaces are the standalone registry grid and the import route /admin/imports/new?entity=player_registrations.

2. Database Schema

Columns

column	type	nullable	default	notes
club_id	string \	null	yes	null	Relationship-bearing column.
competition_id	string \	null	yes	null	Relationship-bearing column.
created_at	string	no	database default or generated	Base table field.
end_date	string \	null	yes	null	Base table field.
id	string	no	generated UUID default	Base table field.
is_primary	boolean	no	database default or generated	Base table field.
jersey_number	number \	null	yes	null	Base table field.
notes	string \	null	yes	null	Base table field.
organization_id	string \	null	yes	null	Relationship-bearing column.
player_id	string	no	none	Relationship-bearing column.
position	string \	null	yes	null	Base table field.
registration_type	string	no	database default or generated	Base table field.
season_id	string \	null	yes	null	Relationship-bearing column.
source_roster_entry_id	string \	null	yes	null	Relationship-bearing column.
start_date	string \	null	yes	null	Base table field.
status	string	no	database default or generated	Lifecycle field when present.
team_id	string	no	none	Relationship-bearing column.
updated_at	string	no	database default or generated	Base table field.

Foreign Keys

column	references	table	on delete
club_id	id	clubs	NO ACTION
competition_id	id	competitions	NO ACTION
organization_id	id	organizations	NO ACTION
player_id	id	players	NO ACTION
season_id	id	seasons	NO ACTION
source_roster_entry_id	id	team_roster_entries	NO ACTION
team_id	id	teams	NO ACTION

Indexes

No migration-defined indexes were discovered in the checked-in SQL history for this table.

Constraints

Unique: none discovered in checked-in migrations.
Check: none discovered in checked-in migrations.

Triggers

No migration-defined triggers were discovered in the checked-in SQL history for this table.

Views (if any)

name	purpose
public.v_player_registrations	Admin registry read model for resolved registration labels.
base-table fallback reads	Development fallback when the registry view is not yet deployed.

3. Import Contract

Accepted Columns

player_id
team_id
club_id
competition_id
season_id
organization_id
club_key
club
competition_key
competition
season_key
season
organization_key
organization
start_date
end_date
status
position
registration_type
jersey_number
is_primary
notes

Resolution Rules

Direct ids are accepted for all relationship columns.
Competition, season, club, and organization may also be provided in normalized key or human-readable form and resolved before write.
Player/team resolution should be treated as required direct relationships in the current contract.

Required Fields

player_id
team_id

Optional Fields

club_id
competition_id
season_id
organization_id
club_key
club
competition_key
competition
season_key
season
organization_key
organization
start_date
end_date
status
position
registration_type
jersey_number
is_primary
notes

Failure Rules

Missing player or team ids fail immediately.
Related competition/season/club/organization mismatches should be resolved before the registration is written.
Invalid status or registration metadata fails normal validation.

4. Frontend Registry Mapping

Grid Columns

label	field	source
Player	player_name	`players.first_name + players.last_name` via `v_player_registrations`
Team	team_name	`teams.name`
Club	club_name	`clubs.name`
Competition	competition_name	`competitions.name`
Season	season_name	`seasons.name`
Organization	organization_name	`organizations.name`
Registration Type	registration_type	`player_registrations.registration_type`
Position	position	`player_registrations.position`
Jersey	jersey_number	`player_registrations.jersey_number`
Primary	is_primary	`player_registrations.is_primary`
Status	status	`player_registrations.status`

Filters

filter	field	type
Organization	organization_id	entity
Season	season_id	entity
Competition	competition_id	entity
Club	club_id	entity
Team	team_id	entity
Player	player_id	entity
Registration Type	registration_type	select
Status	status	select

Display Logic

Registry reads prefer v_player_registrations so the grid can show resolved player, team, club, competition, season, and organization labels from one source.
Registry writes still target the base player_registrations table through a dedicated service path.
Registration type is normalized to the live database contract before write.

5. Lifecycle Rules

Registration status should preserve historical roster context rather than relying on destructive delete.
Updates should preserve the player/team link because downstream participation logic depends on it.

Turfi Platform Documentation