Skip to content

feat(search)!: rename to de-overload “schema” in the search family#595

Open
ddeboer wants to merge 1 commit into
mainfrom
refactor/search-naming
Open

feat(search)!: rename to de-overload “schema” in the search family#595
ddeboer wants to merge 1 commit into
mainfrom
refactor/search-naming

Conversation

@ddeboer

@ddeboer ddeboer commented Jul 10, 2026

Copy link
Copy Markdown
Member

Fix #593.

The search family used “schema” at two granularities (design review §4.4): the whole declaration (SearchSchema, correct — the SQL/namespace sense, and consistent with “GraphQL schema” = the whole API) and one type’s per-collection engine definition (buildCollectionSchema, borrowed from Typesense’s own vocabulary). Separately, SearchType.type held the RDF class IRI — a type’s type, colliding with TS/GraphQL “type”.

This rename de-overloads it: after this, “schema” only ever means the whole set, and the two genuinely misleading names are gone.

Renames

  • SearchType.typeSearchType.class — the RDF class IRI it holds (sh:targetClass); kind stays the field-only discriminator, untouched.
  • buildCollectionSchemabuildCollectionDefinition, CollectionSchemaOptionsCollectionDefinitionOptions, and the file collection-schema.tscollection-definition.ts. Elasticsearch calls this per-index thing a mapping; “definition” is the engine-neutral word, and it returns the whole create-definition (fields plus collection settings), so build + the output noun.
  • Kept (deliberately): SearchSchema, searchSchema() (the bare-noun factory at the top-level entry point people type most), SearchType, defineSearchType (identity + literal capture — a define, not a build).

Plus the search READMEs and ADRs 3/4/8/9 refreshed to the new vocabulary.

Breaking

  • @lde/search: SearchType.type.class.
  • @lde/search-typesense: buildCollectionSchema / CollectionSchemaOptionsbuildCollectionDefinition / CollectionDefinitionOptions.
  • @lde/search-pipeline and @lde/search-api-graphql adapt internally (they route/key on the renamed field); their own public APIs are unchanged.

Pure rename — no behaviour change; the generator-stability snapshot is byte-identical (only its test-name key moved).

The family used “schema” at two granularities (design review §4.4): SearchType’s
RDF-class field and the per-collection engine definition. After this, “schema”
means only the whole set (SearchSchema, GraphQL schema).

- SearchType.type → SearchType.class (the RDF class IRI; sh:targetClass)
- buildCollectionSchema → buildCollectionDefinition; CollectionSchemaOptions →
  CollectionDefinitionOptions; collection-schema.ts → collection-definition.ts
- keep SearchSchema, searchSchema(), SearchType, defineSearchType; kind stays a
  field-only discriminator
- refresh the search READMEs and ADRs 3/4/8/9

BREAKING CHANGE: @lde/search SearchType.type is renamed to .class, and
@lde/search-typesense buildCollectionSchema / CollectionSchemaOptions become
buildCollectionDefinition / CollectionDefinitionOptions. @lde/search-pipeline
and @lde/search-api-graphql adapt internally; their own public APIs are
unchanged.
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.

Rename to de-overload “schema” in the search family (SearchType.class, buildCollectionDefinition)

1 participant