Update Cratis.Chronicle to 19.1.1 - #2704
Open
cratis-bot wants to merge 1 commit into
Open
cratis-bot wants to merge 1 commit into
cratis-bot wants to merge 1 commit into
Conversation
Contributor
Author
Verification gate
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Cratis.Chronicle,Cratis.Chronicle.AspNetCoreandCratis.Chronicle.Testingare updated from18.2.0to19.1.1, picking up 18.3.0, 18.3.1, 18.4.0, 18.4.1, 18.5.0, 18.5.1, 19.0.0, 19.0.1, 19.1.0 and 19.1.1.Added
.FromAll()fluent projections can nowCount,Increment, andDecrementinto a dictionary-typed read model property, with the key resolved per event from anEventContextvalue (e.g. one counter per event type) (All and Dictionaries Chronicle#2464)allblock supports the same dynamic dictionary-key syntax oncount/increment/decrement(All and Dictionaries Chronicle#2464)all/everyblock and.FromAll()/[FromAll]mappings, including the C# dynamic dictionary-key shape--withdrawnexcludes a named release from the wire compatibility gate, which a floor cannot do for the newest release of a major. It refuses a version that is not a released baseline, refuses one from another major, and says out loud when a run was narrowed.EventSourceTypeonForEventSourceIdAndEventTypesRequest, additive and wire-compatible with every released 18.x baseline (getForEventSourceIdAndEventTypes silently ignores the event source type filter Chronicle#4049)skipCompatibilityCheckconnection-string option, alongside the existingskipTlsValidation, for a deliberate, visible, audit-friendly override of the server compatibility check against a known-safe version skew (A newer client refuses an older kernel: the connect-time compatibility check reads every added field as a removal Chronicle#4058)ChronicleOptions.SkipCompatibilityCheck, resolved together with the connection string's option — either input asking to skip is enough, since both default to performing the check[VariantOf<TIdentity>]and[EntersOn<TEvent>]attributes to declare a model-boundread model as one variant of a mutually exclusive group, and
[GlobalFor<TIdentity>]to declare a handler shared by every variant in the group (Read Model Variations Chronicle#3956)
builder.VariantOf<TIdentity>(_ => _.Id).EntersOn<TEvent>()— onthe projection builder (Read Model Variations Chronicle#3956)
Changed
Cratis.Chronicle,Cratis.Chronicle.AspNetCoreandCratis.Chronicle.Testingare updated to19.1.1Cratis.Screenplayto 4.14.0 (Chronicle kernelLanguageService.Compile)@cratis/screenplay-languageto 4.14.0 (WorkbenchProjectionEditor)Fixed
allblock or.FromAll(), with no separatefromblock, never processed a single event at runtime — every event was filtered out before it reached a property mapper (All and Dictionaries Chronicle#2464)EventContextvalue could silently pick up an unrelated read-model property's schema (e.g. a stringidproperty) and produce the wrong value type instead of the expectedint64(All and Dictionaries Chronicle#2464)eventType.id) no longer produces a declaration that fails to re-parseSubscribeToAllEvents, the mechanism behindall/.FromAll()) could get stuck disconnecting itself every time it entered its routing state, because the "no event types on the subscription" disconnect check does not distinguish a genuinely empty subscription from the empty-by-design subscription an all-events observer always hasObserverKeys(used to enumerate the partitions an observer must catch up) built its query with an unconditional$infilter on event type; MongoDB's$inwith an empty array matches no document at all, so an all-events observer — whose definition carries no fixed event type list — always resolved zero partitions to catch upGetForEventSourceIdAndEventTypesnow applies its event source type argument instead of ignoring it, so a read narrowed to one event source type no longer returns events of every other type (getForEventSourceIdAndEventTypes silently ignores the event source type filter Chronicle#4049)ChronicleClient's direct construction path (used outside a host) now actually honors a request to skip the compatibility check; it previously ignored the setting entirelyAddCratisChronicleConnection'sskipCompatibilityCheckparameter now falls back to the connection string's option when not explicitly specified, the same wayskipTlsValidationalready doesReadModelScenario<TReadModel>now builds a variant's projection definition the samevariant-aware way the real discovery pipeline does, so an in-process scenario for a
variant read model actually exercises mutual exclusion instead of behaving like an
ordinary upsert projection
Removed
AppendReceipt,AppendCausationandAppendIdentity, theIncludeReceipt/IncludeReceiptsrequest flags and theReceipt/Receiptsresponse fields.AppendResult.Receipt,AppendManyResult.Receiptsand the kernel plumbing behind them.EventForEventSourceIdalong the way.