Skip to content

Serve the six starship content types - #28

Merged
christopherfowers merged 1 commit into
mainfrom
feat/starship-content-types
Aug 31, 2026
Merged

Serve the six starship content types#28
christopherfowers merged 1 commit into
mainfrom
feat/starship-content-types

Conversation

@christopherfowers

@christopherfowers christopherfowers commented Aug 30, 2026

Copy link
Copy Markdown
Owner

sw5e-database is publishing all 453 items of Starships of the Galaxy
(christopherfowers/sw5e-database#16). The API cannot serve a type it does not
know about, so this registers the six.

The registry stays a closed set

ContentTypeRegistry is hard-coded on purpose — the {type} route value
reaches a path join in the file-backed store and a table selection in the
database-backed one — so the six types are added to it explicitly rather than
the registry being made directory-driven. Sw5eContentDbContext seeds
content_type from the registry, so this also carries the migration those rows
need. The new entries are appended, so no existing row's sort_order moves.

Key Route segment
starship-base-size starship-base-sizes
starship-deployment starship-deployments
starship-equipment starship-equipment
starship-modification starship-modifications
starship-venture starship-ventures
starship-rule starship-rules

Two of the six are awkward in ways the tests pin down. starship-equipment has
a plural identical to its singular, so its key and its route segment are the
same string and the registry indexes both to the same entry. A rule chapter is
titled rather than named, exactly as a source is, so its projection takes the
display name from title — a projection that assumed name would serve
thirteen nameless rows that no list and no search could find.

Cross-references

ContentReferenceMap gains five relations: a modification's prerequisite
modification and prerequisite equipment, a venture's prerequisite venture and
deployment, and the launcher that fires a piece of ammunition.

These are the first references in the corpus that arrive already resolved in
the document
. The import parsed each printed prerequisite clause and wrote the
target it identified into a field beside the wording, so the map reads that
field rather than picking a name out of prose. A clause the import declined to
resolve — a ship size, a weapon mounting, "12 Constitution, no Droid Brain
modification" — deliberately produces no edge, because an unresolvable edge
would sit in the unresolved report for ever as noise hiding the real gaps.

Tests

  • StarshipContentEndpointTests serves all six types over a real fixture of
    eleven starship documents copied from the canonical set: list counts per
    type, hyphenated route segments accepted and near-misses (starship,
    starship-, starship-equipments) refused, a modification's grade and
    resolved prerequisite, ammunition's two damage scales and its launcher, a
    base size's six tier rows and six roles, the rule chapter's title, the
    per-type facets by value, and a search that has to reach a starship
    document's prose rather than its name.
  • StarshipReferenceMapTests covers extraction directly. Resolution, storage
    and re-resolution are type-agnostic and already covered; the rules that
    decide which fields are links are per-type and hand-written, and one
    pointing at the wrong content type would still import cleanly.

The existing assertions on the registry list and its size are updated from nine
types to fifteen.

Companion pull requests

Merge order is sw5e-database → its release → this → sw5e-web.

@FlyTripVisa

Copy link
Copy Markdown

Deploy

Starship content is landing in sw5e-database, and the API cannot serve a
type it does not know about: the registry is a closed set on purpose, because
the {type} route value reaches a path join in the file store and a table
selection in the database one. So the six types are added to it explicitly,
with a migration for the seeded content_type rows, rather than the registry
being made directory-driven.

Two of the six are awkward in ways worth pinning down in tests. Starship
equipment has a plural identical to its singular, so its route segment and its
key are the same string and the registry indexes both to the same entry. A
rule chapter is titled rather than named, exactly as a source is, so its
projection takes its display name from `title` - a projection that assumed
`name` would serve thirteen nameless rows that no list or search could find.

The reference map gains the starship edges. These are the first references in
the corpus that arrive already resolved in the document: the import parsed
each printed prerequisite clause and wrote the target it identified into a
field beside the wording, so the map reads the field rather than picking a
name out of prose. A clause it declined to resolve - a ship size, a weapon
mounting, a Constitution requirement - deliberately produces no edge, because
an unresolvable edge would sit in the unresolved report for ever as noise
hiding the real gaps.
@christopherfowers
christopherfowers force-pushed the feat/starship-content-types branch from df05e39 to 9d7a447 Compare August 31, 2026 01:00
@christopherfowers
christopherfowers merged commit 742f531 into main Aug 31, 2026
4 checks passed
@christopherfowers
christopherfowers deleted the feat/starship-content-types branch August 31, 2026 01:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants