Skip to content

docs: say what a store type name maps to on its own (#56) - #457

Merged
CaffeinatedCoder merged 2 commits into
mainfrom
docs/56-store-type-name-resolution
Oct 25, 2026
Merged

CaffeinatedCoder merged 2 commits into
mainfrom
docs/56-store-type-name-resolution

Conversation

@CaffeinatedCoder

Copy link
Copy Markdown
Owner

Closes #56

Problem

With the plugin active, a range or multirange store type name resolves to this package's types (int4range → Int32Range), and value sets deliberately don't resolve by name. No document said so, so a reader who writes HasColumnType("int4range") on an NpgsqlRange<int> property, or looks a mapping up by name, couldn't know which CLR type they get.

While measuring this I found one more case: with UseValueRangesNodaTime, Npgsql's own NodaTime plugin resolves daterange, tsrange and tstzrange before ours (DateInterval, NpgsqlRange<LocalDateTime>, Interval). The multiranges still resolve to the core RangeSet types. A NodaTime range property is still mapped by its CLR type, so this only matters for a lookup by name.

Change

docs/efcore.md#map-ranges-to-postgresql-columns gets three Good-to-know bullets:

  • A property's type picks its mapping, before any column type. An NpgsqlRange<int> property keeps Npgsql's mapping. An Int32Range property with int8range fails at model building (InvalidOperationException).
  • A range or multirange column type on its own maps to these types, with the NodaTime exception above.
  • An array column type on its own stays Npgsql's. text[] is also the column type of every string[] property, so a value set maps only from a property typed as one. The asymmetry is intended, as the issue expected.

Claim E77 quotes the second bullet and names both new test classes.

Tests

  • StoreTypeNameResolutionTests (EF Core, no database): all 18 range and multirange names; 12 array names, none resolving to a value set; the NpgsqlRange<int> property; the mismatched column type.
  • NodaStoreTypeNameResolutionTests: the three names Npgsql's NodaTime plugin takes first, five that stay ours, and the NodaTime range properties mapped by CLR type.
  • Seeded both ways: a range plugin that ignores store type names fails all 18 name rows, and a set plugin that takes text[] fails the array row.
  • EF Core unit tests (356), NodaTime EF tests (103) and conventions tests (417) pass.

🤖 Generated with Claude Code

docs/efcore.md (Map ranges to PostgreSQL columns) gains three Good-to-know bullets:
- a property's CLR type picks its mapping before any column type: an
  NpgsqlRange<int> with HasColumnType("int4range") keeps Npgsql's, and an
  Int32Range with HasColumnType("int8range") fails at model building;
- a range or multirange name on its own maps to this package's types, except that
  with UseValueRangesNodaTime Npgsql's NodaTime plugin takes daterange, tsrange and
  tstzrange first;
- an array name stays Npgsql's, because text[] also belongs to string[]; a value set
  maps only from a property typed as one. The asymmetry is intended.

StoreTypeNameResolutionTests and NodaStoreTypeNameResolutionTests hold all of it
(claim E77). Seeded both ways: a name-blind range plugin fails the 18 name rows, and
a set plugin that takes text[] fails the array row.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@CaffeinatedCoder CaffeinatedCoder added this to the 10.3.0 milestone Oct 25, 2026
@CaffeinatedCoder CaffeinatedCoder added documentation Improvements or additions to documentation found-by/oracle Found by the generated-oracle machinery (claims × API surfaces) package/efcore Affects CodoMetis.ValueRanges.EFCore.PostgreSQL package/efcore-nodatime Affects CodoMetis.ValueRanges.EFCore.PostgreSQL.NodaTime labels Oct 25, 2026
@CaffeinatedCoder
CaffeinatedCoder merged commit 61c94ef into main Oct 25, 2026
14 checks passed
@CaffeinatedCoder
CaffeinatedCoder deleted the docs/56-store-type-name-resolution branch October 25, 2026 20:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

documentation Improvements or additions to documentation found-by/oracle Found by the generated-oracle machinery (claims × API surfaces) package/efcore Affects CodoMetis.ValueRanges.EFCore.PostgreSQL package/efcore-nodatime Affects CodoMetis.ValueRanges.EFCore.PostgreSQL.NodaTime

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Document that range mappings resolve by store type name

1 participant