Skip to content

Entity

Base interface every canonical entity in the data platform implements — the cross-sport supertype for jockeys, trainers, horses, owners today and greyhounds / players / teams / referees as new sports onboard. Mirrors the participants table’s identity columns plus the alias-merge surface (M22, REQ-009): every subtype carries these six fields verbatim. Clients can fetch an Entity polymorphically and inline-fragment on the concrete subtype for type-specific fields; the entity-config layer in @podium/products uses this interface as the target for a shared EntityBase fragment so detail queries don’t re-spell the same six fields per subtype.

Naming: Entity aligns with the rest of the GraphQL surface (commentsForEntity(entityType, entityId)) and the entity-config vocabulary (EntityConfig, EntityKey, defineEntity). The DB participant taxonomy (participants table, @podium/data-types’s Participant interface) is left untouched — those names are racing- rooted but the table+TS schema is where the persistence semantics live.

FieldArgsTypeDescription
idID!
nameString!
sportIdID!
legacyIdsLegacyIds
createdAtDateTime!When the participant row was first inserted (participants.created_at).
aliases[ParticipantAlias!]!Records merged into this canonical via the M22 merge flow (REQ-009).