Stratara 4.5.0

A release about reads that cost more the more the store holds. Loading an aggregate read its stream and its
snapshot through every partition of the store, so every command grew slower as the store grew. A write context
that applies ApplyGlobalEntityConfiguration() also lost the index on the event stream's sequence number, which
left the hashing worker, reading in sequence order and the store's head without an index. Every read of one stream
is now confined to its partition, and the write model declares the indexes it was missing, whichever key the
context gives the event stream. No public type or member changes, but the write context needs a migration, and a
write context that overrides ConfigureConventions without calling base is now refused at start-up.

Upgrading:

• If your store holds events written before 3.0.0, check it first. Releases before 3.0.0 worked out a
  stream's partition with another formula, and the store now reads a stream only in the partition its id gives.
  The composition guide (A store written before 3.0.0) gives a check that needs nothing but the database, and a
  repair that moves the rows to their partition without touching the hash chain. A store that 3.0.0 or later wrote
  from its start has nothing to check.
• Generate an EF Core migration for your write context. It adds up to three indexes and changes no table or
  column: ix_event_stream_entry_sequence_number (unique, only where the event stream is not keyed by its sequence
  number, which ApplyGlobalEntityConfiguration() makes it), ix_event_stream_entry_unhashed_sequence_number
  (the entries whose hash is still null) and ix_event_chain_anchor_sequence_number. A host that does not migrate
  fails at Migrate() on pending model changes, as with any schema addition.
• If you declared these indexes yourself, remove your declarations first. Under the same names and
  definitions, the migration then leaves them as they are. A (stream_id, version) index you added to bridge the
  stream reads is no longer needed and can be dropped.
• On a large store, create the indexes without blocking writes. The schema section of the composition guide
  shows a migration that creates them with CREATE INDEX CONCURRENTLY.
• A context that overrides ConfigureConventions calls base.ConfigureConventions. WriteDbContext<TContext>
  declares the sequence-number indexes there. A write context whose override does not call it is now refused when
  its model is built, at start-up and in dotnet ef alike, with an InvalidOperationException that names the
  context, so it never runs or migrates without the indexes. An override that was fine on 4.4 because the
  method was empty there needs base.ConfigureConventions(configurationBuilder); now.
• An entry or snapshot written outside the framework has to carry its stream's partition. The store writes
  each one with the partition its stream id gives it, through BucketCalculator.GetBucketId, and now reads one
  stream only there. A row a host inserted itself under another partition, in a test fixture or an import, is no
  longer found by the reads of its stream.

Fixed

• Loading an aggregate costs what its stream holds. The reads of one stream (whether it exists, its first entry,
  a range of versions, its current version) and of its snapshot conditioned on the stream id alone. The indexes that
  serve them begin with the partition, so PostgreSQL before 18 walked the whole index for each of them, and a
  command loads several. They now condition on the partition as well. On 300,000 events, reading a stream of three
  went from 2,404 pages to 6.
• The sequence number stays indexed under ApplyGlobalEntityConfiguration(). That convention keys every entity
  by Id, the event stream included, which dropped the key the framework had put on the sequence number. The
  hashing worker's reads, reading the store in sequence order and the store's head then scanned the whole table on
  every pass. The write model now declares a unique index on the sequence number wherever it is not the key.
• The hashing worker reads only what is still unchained. An index over the entries whose hash is null lets
  each pass read the backlog and not the chained history before it. Its filter names the column your model maps the
  hash to.
• The latest anchor is found by index. The hash chain's anchors are indexed by sequence number, so finding the
  last one no longer sorts every anchor on every pass.