Proto commits in FgForrest/evitaDB

These commits are when the Protocol Buffers files have changed: (only the last 100 relevant commits are shown)

2026-08-04

feat: expose the formula plan and flatten the GraphQL telemetry profile Stage D of the query telemetry campaign, covering issue items 8 and 5. Item 8 - GraphQL publishes the profile as a typed, pre-order flat list of steps carrying `level` and `stepsCount`, rather than a recursive object. In GraphQL the client picks the selection depth, so a nested `steps` field would force a selection set as deep as the deepest query ever profiled and silently truncate anything below it. The `hierarchy` extra result already makes the same trade for the same reason, and a flat list is the shape a flame chart consumes. REST keeps the nested tree. Item 5 - `queryTelemetry(PLAN)` additionally returns the formula plan the planner built: every index-selection alternative it costed *including the ones it rejected*, plus the plan that actually ran. The renderer computes nothing. `Formula#getMemoizedResult()` is the new primitive that makes that possible - it reports whether a result is available for free, never producing one. A forcing renderer would execute the plans the engine had decided to skip, so asking for a profile would change the query instead of observing it. Nodes that never ran report no `actualCost` and no `resultCount`, which is the honest answer: absent is not zero. `QueryTelemetryContent` follows the `ConstraintWithDefaults` pattern used by `priceHistogram`/`HistogramBehavior` - `TIMINGS` is the default, is always stored, and is omitted only from the EvitaQL string form, so `queryTelemetry()` and `queryTelemetry(TIMINGS)` are the same constraint and both print as the former. The level is single-valued rather than a set, because `queryTelemetry(TIMINGS, PLAN)` would be self-contradictory. Two things worth knowing: - `QueryTelemetrySerializer` used to write nothing, which was correct while the constraint was stateless. Once it gained an argument that became silent data loss - a `queryTelemetry(PLAN)` arriving through the Java driver or replayed from a traffic recording would have been downgraded to the default with no error anywhere. A constraint gaining its first argument needs its Kryo serializer revisited. - The non-forcing guarantee has a dependency: `AbstractFormula`'s default `getCostInternal()` computes every inner formula, and the visitor does read `getCost()` on a short-circuited AND. It stays safe only because `AndFormula` overrides the cost path with one that short-circuits at the same index, and `NotFormula` handles its case explicitly. A future formula type that skips children while inheriting the default would break it. Breaking changes, all safe today because nothing consumes these surfaces yet, and all deliberate rather than compatible workarounds layered over shapes that had to change regardless: - REST require shape: `"queryTelemetry": true` -> `"queryTelemetry": "TIMINGS"` or `"PLAN"`. A single-argument constraint publishes unwrapped. - GraphQL: a bare `queryTelemetry` field selection is no longer valid, and the field returns a list. Ref: #1341

The documentation is generated from this commit.

feat: give query telemetry typed, actionable metrics per step Telemetry could say *where* a query spent its time but never *why*: the only numeric planner signal that escaped the engine was an estimated cost embedded in an English sentence. Steps now carry typed measurements alongside the prose. Engine: * `QueryTelemetry.StepMetric` - a closed enum indexing a `long[]` allocated on the *first* `recordMetric` call and never before. A `Map<String, Number>` would have allocated and boxed on a path that must stay free, and would have let each recording site invent its own key. `Long.MIN_VALUE` marks a metric as unset, so "not measured here" stays distinct from a measured `0` - which four of these can legitimately be. `getMetric` returns `OptionalLong`, so reading one allocates nothing on the embedded path. * `QueryPlan#recordQueryMetrics` attaches the eight query level numbers the JFR `FinishedEvent` already computes onto the still-open `OVERALL` root - none of which previously reached the client debugging the one slow query it cared about. The guard is telemetry's own rather than the event's: the two are switched independently, and folding them together would drop the metrics whenever JFR happened to be off. * Both costs report `Long.MAX_VALUE` for "not known" - the estimate on arithmetic overflow, the real one when the formula was never computed - and that is mapped to an unrecorded metric rather than a nine-quintillion cost. Eight metrics ship, not the ten originally sketched. `LOOPS` has no writer, and a permanently-null field is the same defect the REST schema correction just fixed; `RECORDS_FOUND` and `ACTUAL_CARDINALITY` are one value under two names. The enum only ever grows by appending, so both can be added when something actually records them. External APIs: * Published as a nested `metrics` object rather than flattened onto every node. Only the root carries metrics, so flattening would repeat eight nulls on every node of a forty-node tree. * gRPC fields are `optional` - proto3 implicit presence cannot distinguish a measured `0` from an unmeasured metric, and `prefetched` is a real `bool` rather than the `1`/`0` the engine packs internally. * Metrics round-trip through `ResponseConverter`, unlike `selfTime`. Self-time is server-derived and any client can recompute it; metrics are measured, so dropping them would make embedded and remote disagree about the same query. The "metrics live on the root only" contract holds for a non-local reason: a nested query's planning context is seeded with the step that spawned it, not the tree root, so `getTelemetryRoot()` there returns an inner node. What saves it is that nested queries are planned through `planNestedQuery` and never reach `QueryPlan#execute`. That is spread across three classes, so it is pinned by a test that runs a real nested query and walks the whole subtree, not just the root's direct children. Tests also cover the REST and GraphQL response shape end to end for the first time - `queryTelemetry` had no wire-level coverage in either API, so the `selfTime` and `formattedSpentTime` fields added earlier in this campaign were shipping unasserted too. Ref: #1341

feat: turn query telemetry from a phase timer into an actionable query profile Engine: * `pushStep`/`popStep` now take a `Supplier<String>` instead of an eagerly built `String`. Every annotated site previously paid for string concatenation even with telemetry switched off; the hottest of them — `ReferencedEntityFetcher` (once per reference name per page) and `QueryPlanner`'s per-candidate-index `toStringWithCosts` — now cost nothing unless the profile is actually collected. The eager overloads are removed rather than kept alongside, so no call site can regress to them. * `QueryTelemetry#annotate(String)` appends an argument to an already open step. `SortResolutionStrategies` has to record its tally on the *current* step, and the alternative — relaxing the one-shot assert in `finish(String...)` — would throw on the `NestedContextSorter` path, which pushes `EXECUTION_SORT_AND_SLICE` with a description already set. Appending independently of `finish()` keeps that assert meaningful. External APIs: * Telemetry nodes carry `selfTime` (`spentTime` less the time accounted for by direct children) plus pre-formatted `formattedSpentTime` and `formattedSelfTime`. Self-time is derived at the API boundary, not in the engine, so the zero-cost-when-off guarantee is untouched. * BREAKING: the REST/GraphQL `spentTime` property is typed `Long` instead of `String`. The schema declared a string for what has always been serialized as a number; this corrects the contract rather than working around it, and `formattedSpentTime` is what clients wanting the human-readable form should read instead. * gRPC gains `GrpcQueryTelemetry.selfTime` (field 7). It is server-derived; the Java driver rebuilds telemetry through the explicit constructor and does not read it back. Documentation: * Requirement JavaDoc corrected — `start` is a monotonic reading with no epoch and must never be rendered as a date, the overhead is per phase, and the claim that the tree exposes the formula evaluation hierarchy was untrue. * The user-facing telemetry page documents `startedAt`, `selfTime` and the `formatted*` fields, drops the GraphQL `format` argument that no longer exists, and warns that tree shape varies per query and that collecting a profile perturbs what it measures. * JavaDoc debt paid down across the touched classes, including members that predate this change. `QueryPlanningContextTelemetryTest` pins the laziness guarantee: with telemetry off, no supplier is ever invoked. Ref: #1341

2026-08-02

fix: reset sinceIndex when sinceVersion is clamped down in reverse paging ChangeCaptureConverter.toChangeCaptureRequest (reverse paging) clamped an explicit sinceVersion above the requested catalog version down to it, but carried an explicit sinceIndex over unchanged. That index was computed by the client against its own, now-discarded version and no longer identifies a valid position in the clamped-to version - the same defect class this PR's first commit fixed elsewhere. toChangeCaptureRequestForward already guards the analogous forward case via its own versionClamped flag. The fix narrows the reset to only the genuine clamp-down case (an explicit sinceVersion exceeding the bound) rather than reusing the forward helper's condition verbatim, which would also reset the index whenever sinceVersion is merely absent - breaking the already-covered and intentional behavior of honouring an explicit sinceIndex alongside an omitted sinceVersion. Also documents the reset in the sinceIndex proto field comment, which described the direction-based default but not that a clamp discards an explicit value. Ref: #1349

2026-08-01

feat: add forward-chronological mutation-history RPCs and stream Adds getMutationsHistoryForward/getMutationsHistoryReversed to EvitaSessionContract (deprecating the direction-ambiguous getMutationsHistory), and their gRPC counterparts GetMutationsHistoryForward/GetMutationsHistoryPageForward, completing the CDC mutation-history surface alongside the existing reverse-chronological RPCs. - reads forward history via the WAL's live-safe reader (getCommittedLiveMutationStream), not the unsafe one meant only for a WAL that is no longer being actively written - forward paged timeFrame.to is an inclusive stop bound, matching the documented contract; resolves the true last-eligible version via MaterializedVersionBlock.endVersion() rather than startVersion(), which under-selected whenever a checkpoint batches more than one catalog version (applied the same correction to the reverse handler's equivalent resolution, for consistency) - a timeFrame.from moment in the future now yields an empty page instead of clamping down to the newest known block; a from in the past is left checkpoint-granular like the reverse RPC already is, since there is no lag-free way to tell "nothing committed after this" apart from "committed after this but not yet checkpointed" - a forward anchor clamped up to the floor resets sinceIndex to 0 instead of carrying over an index meant for a different version - the forward streaming RPC now closes its mutation stream on normal completion via try-with-resources, matching the paged handlers Ref: #1349

fix: paginate gRPC mutation-history reads without losing or duplicating records GetMutationsHistoryPage groups the change-capture stream by (version, index) via the new ChangeCatalogCaptureRecords helper, so a page never splits an entity/schema mutation from the local-mutation captures it produced. hasNext is computed from a one-record lookahead instead of leaving the last page ambiguous, and the resolved sinceVersion is echoed back to the client so a multi-page traversal can pin its anchor across pages instead of re-resolving "current version" on every call - which previously let concurrent commits shift the anchor and skip or duplicate records between pages. Ref: #1349

2026-07-31

docs: state the evitaDB release version on every proto deprecation Extends the proto documentation convention with the same `since` discipline `@Deprecated(since = "X")` already follows on the Java side (see .claude/rules/deprecation-policy.md): every `[deprecated = true]` field or `option deprecated = true` message must state the evitaDB release (`YYYY.MAJOR`) it became deprecated in, since proto has no structured attribute to hold it. Backfills all 40 existing deprecations across the gRPC surface with their actual version, found by walking each element's git history to the commit that introduced it and resolving the first release tag that contains that commit - the same method tools/audit-deprecated-since.sh uses for Java. Also fixes a bare `[deprecated = true]` on GrpcCreateReflectedReferenceSchemaMutation.faceted that carried no reason at all, unlike its sibling messages in the same file. Ref: #1350

fix: correct gRPC mutation-history CDC bugs and null-filter placement Fixes three defects in the gRPC mutation-history/CDC surface: - GetMutationsHistoryPageRequest ignored `sinceIndex` when set without `sinceVersion`, silently collapsing the anchor to index 0 - the slot reserved for the transaction header - instead of the direction-appropriate default. - The inverse ChangeCatalogCapture converter dropped the `infrastructureMutation` body arm entirely, losing that mutation kind on round-trip. - GetTransactionOverview crashed when a requested catalog version was unknown to history, because the null placeholder for unknown versions was passed straight into a @Nonnull converter. Null-filtering for unknown catalog versions is moved to its true origin, DefaultCatalogPersistenceService, instead of the gRPC service layer - CatalogContract and EvitaSession are pure delegates, and a pre-existing long-running test already calls Catalog#getCatalogVersionDescriptors directly, bypassing any session. Filtering at the persistence layer fixes every caller uniformly rather than relying on each one to remember to filter. Also de-caveats GrpcEvitaSessionAPI.proto and GrpcChangeCapture.proto now that the underlying bugs are fixed, and drops issue-tracker self-references from proto/test comments - issue numbers rot once closed and mean nothing to non-Java client generators reading the same comment. Ref: #1349

docs: rewrite gRPC proto documentation and add buf lint enforcement Documentation-quality audit of evitaDB's .proto surface (issue #1350): rewrites ~387 weak/tautological field, message, enum, and RPC comments across 16 .proto files so the comments are accurate, complete, and usable as the primary API reference for non-Java gRPC clients. Establishes and applies consistent conventions for wrapper-type (google.protobuf.*Value) nullability, units, the two paging models in use (1-indexed pageNumber vs. 0-indexed offset/skip), oneof exclusivity, and deprecation phrasing. Also documents GrpcEvitaAPI.proto, which the issue's own "worst offenders" table flagged but never assigned to a chunk. - Adds .claude/rules/proto-documentation.md, the house convention all of the above follows (wrapper nullability, units, paging models, oneof exclusivity, deprecation phrasing, no Javadoc markup in proto comments since it leaks into other-language codegen, TOBEDONE #issue markers instead of bare TODO). - Regenerates the 294 affected Java files under evita_external_api_grpc/shared/.../generated via protobuf-maven-plugin (protoc 3.25.8); comment-only diffs, verified via per-file field/message/enum/rpc count parity against the pre-edit baseline. - Fixes the matching hand-written doc on EntitySchemaDescriptor.java#withHierarchy to the same corrected wording as GrpcEntitySchema.proto. - Adds buf lint (evita_external_api_grpc/shared/buf.yaml, COMMENTS ruleset only - STANDARD's naming-convention rules would force renaming ~1000 established camelCase fields that mirror the generated Java accessors) plus tools/lint-proto.sh, a Docker-based wrapper needing no local buf install. Wires it into ci-dev.yml as the first step, before JDK setup/build, and adds evita*/**/*.proto to the workflow's path filter so a proto-only push actually triggers the pipeline. - Adds a Claude Code PostToolUse hook (.claude/hooks/lint-proto-on-edit.sh, .claude/settings.json) that runs the same buf lint immediately after Claude edits or writes a .proto file, surfacing violations mid-turn instead of only at CI time. Six real (non-documentation) bugs surfaced while tracing semantics for accurate docs were left unfixed and posted separately to issue #1349, since they aren't in this issue's scope. Ref: #1350

2026-07-30

feat: report telemetry start as an offset and anchor the tree with startedAt `QueryTelemetry.start` carried the server's raw `System.nanoTime()` reading - a monotonic counter with no defined epoch. Over the wire that value is unusable: it cannot be rendered as a time, cannot be compared to anything the client holds, and only becomes meaningful once the client subtracts the root step's start itself. Every remote client had to know that quirk and do the subtraction by hand. The external APIs now normalize `start` to the number of nanoseconds elapsed since the root step began, so the root reports `0` and every node is directly plottable on a timeline. Two conversion points cover all three remote surfaces: `QueryTelemetryDto` (REST and GraphQL) and `GrpcQueryTelemetryBuilder` (gRPC, and therefore `EvitaClient`). The engine object is deliberately left alone. `start` is `final` and the root is handed to the client in `QueryPlan#fabricateExtraResults` before `finalizeTelemetry()` runs, so it cannot be rewritten in place; and for an embedded caller the raw reading is genuinely useful, because it shares the caller's clock. `QueryTelemetry#start` now documents both meanings. Normalizing alone would have removed the last trace of wall-clock information from the payload, so the root step is additionally stamped with `startedAt` - the instant the query began, captured once per query through the new `QueryTelemetry#root(...)` factory. The wall-clock position of any node is `startedAt` plus that node's `start` offset. It travels as `GrpcOffsetDateTime` over gRPC and as an ISO-8601 string over REST and GraphQL, whose `ObjectMapper` has no JavaTimeModule registered and would fail on a raw `OffsetDateTime`. Compatibility: any client treating `start` as absolute was already wrong, and a correct one computed `node.start - root.start`, which is exactly the new value. A new driver against an old server reads raw `nanoTime` as an offset and gets nonsense, but the field was never usable remotely, so nothing that previously worked breaks. One capability is genuinely lost. `start` was the only cross-query timing signal the payload carried, so comparing two queries' starts to prove they overlapped no longer works. That premise is recorded in the `@Disabled` reason of `CatalogGraphQLAsyncQueriesFunctionalTest`, whose overlap assertion relied on it.

2026-07-27

feat: expose engine settings and capabilities via GetEngineSettings management RPC Clients had no reliable way to read the engine-wide default conflict resolution. The only path was getConfiguration, which returns the raw YAML configuration and is refused outright while the engine runs in read-only mode, so a client could not resolve the effective conflict resolution for an entity type: the catalog and entity schemas already travel over the wire, but the engine default that forms the base of the precedence walk did not. Add a GetEngineSettings management RPC returning a curated EngineSettings record. It carries no sensitive values, is therefore unrestricted, and stays readable in read-only mode - the engine implementation deliberately skips the writability assertion that getConfiguration performs. Alongside the conflict resolution it reports the capabilities a client may need to rely on: whether time travel, change data capture, traffic recording and the query cache are enabled. The enabled external APIs with their URLs and the read-only flag are deliberately absent - they already ship in the server status. The record is flat rather than mirroring the configuration sections. Only a small fraction of the configuration is client-actionable - the vast majority are internal tuning knobs a client can neither act on nor benefit from - and which section a value happens to live in is an accident of the server's own configuration history that the caller should not have to know. Two closely related timeouts already sit in different sections today. The wire types were already in place: GrpcConflictResolution and its enums live in GrpcEnums.proto and ConflictResolutionConverter already round-trips them for catalog and entity schemas. The client refuses a response whose conflict resolution is absent rather than letting it decode to the zero enum value, which would read as "no conflict detection at all". No fallback is attempted when an older server answers UNIMPLEMENTED - such a server predates configurable conflict resolution entirely, and silently substituting a default would mask a version mismatch. getConfiguration and its read-only gate are left untouched.

2026-07-17

feat: on-demand export of buffered traffic recording Adds an on-demand export of the currently buffered traffic-recording window, independent of the existing start/stop streaming recorder task. Callers trigger ExportTrafficRecording over the gRPC traffic-recording API and download the resulting ZIP through the file-fetch API; the export takes a consistent one-shot snapshot without starting, stopping or interrupting live recording. Along the way this fixes a family of concurrency and wrap-around correctness bugs in the disk ring buffer: - replaces OS FileChannel region locks with an in-JVM span lock, so the writer no longer crashes with OverlappingFileLockException when a reader holds an overlapping span, and two readers no longer silently drop each other - distinguishes slot validity from session identity: an evicted-and-reused slot passed the validity check, so an export could splice a foreign session's bytes into the archive - makes ringBufferHead/ringBufferTail volatile - fixes three RingBufferInputStream wrap bugs (single-byte off-by-one, bulk read no-advance, skip without seek) - stops lockAndWrite swallowing IOException - fixes isSessionLocationStillInValidArea for a fully-packed buffer (head == tail) - fixes a partial export file leak on failure, a block leak on MemoryNotAvailableException, and a duplicate onNext in stopTrafficRecording - reconciles the filter-predicate and sampling JavaDoc with the actual semantics - removes a stale malformed-FQN TrafficRecorder SPI registration file Adds a JMH suite covering the write, read, flush and index paths plus an export-interference benchmark, and cuts 656-712 B/op from recordQuery by avoiding a redundant label merge. Ref: #1282

2026-07-14

feat: propagate granular conflict resolution through storage, WAL and external APIs Extends the schema & config surface (b23002324) with the remaining serialization and API layers for issue #503: - Storage and WAL Kryo serializers now persist the per-schema conflictResolutionOverride and the entity/catalog-level ConflictResolution. serialVersionUIDs are bumped once with _2026_1/_2026_2 backward-compatible readers so pre-#503 catalogs and unreplayed WAL still load. - gRPC (protos + converters), GraphQL and REST expose the new schema properties and the Set*/Modify* conflict-resolution mutations at full parity. - Fix a data-safety defect: CatalogSchema is registered in both SchemaKryoConfigurer and CatalogHeaderKryoConfigurer; the reader-less header registration overrode the good one (Kryo registers by class, last-write-wins), orphaning every pre-#503 catalog on open with StoredVersionNotSupportedException. The header registration now carries the _2026_1 reader too. - Deduplicate the identical conflict-resolution parse/serialize helpers into ConflictResolutionMutationConverterSupport. - Add the kryo-bwc-audit skill to mechanically verify serialVersionUID bumps and backward-compatible reader coverage across all configurers before a release. Adds unit and functional coverage across every touched layer, including a byte-fixture backward-compatibility regression for the CatalogSchema fix. Ref: #503

2026-07-07

feat: atomic partial rollback for gRPC entity mutations (1:1 with embedded) A single caught EntityUpsertMutation / EntityRemoveMutation failure inside a gRPC transaction previously poisoned the whole transaction — the commit was rejected with a RollbackException — unlike the embedded engine, where the per-entity savepoint reverts only the failing entity and the surviving mutations still commit. Make the gRPC driver behave identically to embedded: - Add SessionFlags.TRANSACTION_CONTROLLED_EXTERNALLY; EvitaSession pins the base nesting level to 1 for such sessions so every RPC mutation runs nested and never self-poisons the transaction (TransactionException still does). EvitaService sets the flag for remote read-write sessions. - Add a `rollback` field to GrpcCloseRequest / GrpcCloseWithProgressRequest; EvitaSessionService honors it by marking the session rollback-only before close, so the commit-vs-discard decision belongs to the client. - Mirror the embedded nest machinery in EvitaClientSession and route updateCatalog through session.execute(...): the transaction is marked rollback-only only when an exception escapes the root frame uncaught, and that decision is sent to the server at close time. Add gRPC driver tests covering caught-and-continue (survivors commit, no orphan facet/price index residue), uncaught escape (whole transaction rolls back), direct read-write session poisoning, and the close-with-progress rollback path. Ref: #760

2026-05-27

Merge pull request #1192 from FgForrest/1161-histograms-add-range-source-attribute-support-and-multi-histogram-schema feat: range source-attribute support and multi-histogram schema for reference histograms

feat: range source attribute support and multi-histogram schema for reference histograms Allow reference histograms to bucket over NumberRange-typed source attributes, distributing each range across every bucket its endpoints overlap, and support multiple named histograms per reference/scope with per-histogram `assignedWhen` partition selectors. Covers the full stack: annotations, schema DTOs/builders, mutations, engine indexing and the range-aware bucket sweep, gRPC/GraphQL/REST surfaces, and Kryo/WAL serializers. Tests add an oracle-based per-bucket assertion for range histograms that independently re-derives expected occurrences from the seeded ranges, replacing the prior tautological `sum == overallCount` check. Ref: #1161

2026-05-26

feat: add FETCHING_REFERENCE_BODIES query telemetry phase Introduces a single aggregate telemetry phase that wraps the orchestration of loading all referenced entities for a result page (per-reference predicate setup, referenced primary key collection, deduplication, recursive dispatch and the nested storage reads exposed as FETCHING_REFERENCES children), pushed inside ReferencedEntityFetcher around the prefetch call. Also fixes a telemetry nesting bug where the reference-index step was popped from the nested query context instead of the execution context, which flattened the FETCHING subtree and skewed per-step timings. Includes the gRPC enum value (proto + EvitaEnumConverter) and the regenerated gRPC stubs.

2026-05-15

fix: backport CDC gRPC streaming fixes and heartbeat protocol from dev Brings release_2025-7's CDC subscriber stack in line with dev so K8s rolling deploys are safe in both directions (new-client/old-server and old-client/ new-server) and so long-lived streams survive Armeria timeout extension and catalog replacement without leaking or deadlocking. Wire-neutral hardening (no proto bump): - Switch all CDC/streaming response timeouts to TimeoutMode.SET_FROM_NOW so a silent stream unblocks within streamingTimeout of the last event instead of accumulating an unbounded EXTEND deadline. - Re-key EvitaClient.activePublishers via a sealed CapturePublisherKey (SystemCaptureKey / CatalogBoundCaptureKey) so two catalogs sharing the same filter criteria no longer collide. - Once-only stream finalization on the server side via AtomicBoolean + markStreamDead, with non-blocking cancel handlers (whenComplete instead of Future.get) and deferred subscription.cancel() via CompletableFuture.runAsync to avoid event-loop blocking and catalog-replacement deadlock. - Client-side serverSideClosed flag prevents re-cancelling a stream the server has already terminated; delegate.close() runs on subscription.executorService to break the catalog-replacement deadlock when close() fires on the gRPC event loop. Heartbeat protocol (proto-additive, backward compatible): - Add GrpcHeartBeat message, HEARTBEAT response-type enum value, and heartBeat field on both register-capture responses; new HeartBeat record and HeartBeatSensor interface for the client API. - Server-side AbstractChangeCaptureSubscriber drives a periodic heartbeat task and emits ack/heartbeat/change frames through emitOnNext with proper setOnCancelHandler / setOnCloseHandler wiring on the service-method thread. - Replace inline subscribers in EvitaService and EvitaSessionService with the new subscriber/* classes. Subscription-id and heartbeat extraction are deliberately split into two abstract methods (extractSubscriptionId / extractHeartBeat) instead of one combined method that synthesizes a sentinel HeartBeat for legacy servers. A synthesized heartbeat with lastObservedVersion=0 would clobber any persisted catalog-version checkpoint maintained by a HeartBeatSensor on first connect to a legacy server. The split lets the subscription id flow through while suppressing the spurious heartbeat dispatch. Catalog-side ChangeCatalogCaptureSubscriber omits the SemVer clientVersion parameter present on dev because release_2025-7's ChangeCaptureConverter does not have the SemVer-aware toGrpcChangeCatalogCapture overload; the single-arg variant is used instead. Out of scope (dev-only features intentionally not backported): HostSystemEvent capture criteria, BackupCatalogWithProgress streaming RPCs, GrpcCatalogVersionAtResponse reshape, SemVer-aware converter overload, application-level lastKnownVersion persistence.

2026-05-08

feat: coalesce GraphQL/REST schema refresh on catalog schema changes Introduces a new `HostSystemEvent.CatalogSchemaUpdated` variant that is emitted exactly once per session close (WARMING_UP) or per transaction commit (ALIVE), regardless of how many `ModifyCatalogSchemaMutation`s were applied. GraphQL and REST refreshing observers no longer rebuild their schemas on every per-mutation engine event; instead they react to the coalesced host event, eliminating the historical refresh storm. Key changes: - New `HostSystemEvent.CatalogSchemaUpdated` host event with gRPC, GraphQL descriptor, and REST exposure. - `Evita#replaceCatalogReference` and `EvitaSession#executeTerminationSteps` emit the coalesced event; `ExpandedEngineState#replaceCatalogReference` returns a boolean indicating whether the schema actually advanced. - `SystemGraphQLRefreshingObserver` / `SystemRestRefreshingObserver` rebuild only on the host event, not on per-mutation captures. - WAL-replay no longer re-emits a schema-update event (the catalog is not yet in the live view, so live observers cannot have seen the pre-replay schema — preventing a double rebuild). - Tests trimmed to coalescing-specific contracts; full dispatch coverage is now owned by the GraphQL/REST functional subscription tests. Ref: #1153

2026-05-07

feat: introduce HostSystemEvent on system CDC stream Adds HostSystemEvent — a host-local, advisory, non-replicable event class on the system CDC stream — and surfaces it through the existing ChangeSystemCaptureCriteria pattern. First variant CatalogInstalledIntoLiveView is emitted when a real Catalog replaces an UnusableCatalog placeholder in the live view, fixing the gap where auto-upgraded catalogs were internally usable but externally invisible (GraphQL/REST endpoints not registered, Lab UI stuck in BEING_ACTIVATED) until server restart. API model: - new SystemCaptureArea enum (ENGINE, INFRASTRUCTURE) - new ChangeSystemCaptureCriteria with builder - ChangeSystemCaptureRequest gains criteria[] and engineArea() / infrastructureArea() builder methods - new sealed HostSystemEvent + CatalogInstalledIntoLiveView record - SystemCaptureBody marker implemented by EngineMutation and HostSystemEvent; ChangeSystemCapture#body widened accordingly - default-criteria divergence vs catalog stream: system stream defaults to ENGINE only; INFRASTRUCTURE must be opted in Engine: - Evita#replaceCatalogReference emits CatalogInstalledIntoLiveView via SystemChangeObserver on first install (UnusableCatalog → real) - SystemChangeObserver gains processHostEvent path bypassing the recent-events cache (live-tail only) - ChangeSystemCaptureSharedPublisher honors criteria filter and enforces live-tail-only delivery for INFRASTRUCTURE - SystemAreaPredicate family added to MutationPredicateFactory External APIs: - SystemGraphQLRefreshingObserver / SystemRestRefreshingObserver opt into infrastructureArea() and react to CatalogInstalledIntoLiveView by registering the catalog endpoint without restart - gRPC: GrpcChangeSystemCapture grows HostSystemEvent oneof branch, GrpcSystemCaptureArea + GrpcChangeSystemCaptureCriteria carrier - REST/GraphQL descriptors and serializers updated end-to-end - Lab UI subscribers will opt in via the new criteria Tests cover boot-time auto-upgrade reproduction, ordering with the preceding UpgradeCatalogFormatMutation, default vs explicit criteria behavior, and live-tail-only semantics for late subscribers. Ref: #1151

2026-05-05

feat: support fetching full price range for master product variants Introduce priceForSaleMin/priceForSaleMax fields on entity output that expose the lowest and highest sellable prices across a master product's variants. New PriceRangeForSale and PriceRangeForSaleWithAccompanyingPrices contracts are surfaced through the API, GraphQL, REST and gRPC layers, with matching documentation, examples and tests. Ref: #1086

2026-04-28

feat: enforce WAL-first discipline for engine state to prevent version drift Introduce explicit catalog lifecycle states (MISSING, OUT_OF_DATE, BEING_UPGRADED) and the engine mutations that drive transitions between them, so every change to engine state goes through the WAL before being applied. This eliminates VersionWAL drift between in-memory engine state and the persisted log, and surfaces previously silent inconsistencies as explicit, recoverable errors. Key changes: - Add MarkCatalogMissingMutation/UpgradeCatalogFormatMutation along with their operators, converters (gRPC, GraphQL, REST) and serializers. - Add CatalogMissingException, CatalogRequiresUpgradeException and CatalogBeingUpgradedException with mappings in JsonApiExceptionHandler. - Bump engine state to EngineStateSerializer_2026_1 with backward-compat dispatch via the existing _2025_6 serializer; persist CatalogInventoryDivergence and UnprocessedTransactionRecord in WAL. - Wire DefaultUpgradeExecutor / UpgradeExecutor SPI into EngineTransactionManager so format upgrades replay through the WAL. - Reorganize WAL exceptions under spi/store/engine/exception and remove the now-obsolete EngineMutationLogCorruptedException and the EngineTransactionMutationWithWalFileReference duplicate. - Add functional and unit tests covering boot-time WAL divergence, forward replay, mutation operators, converters, and exception handling. Ref: #1137

2026-04-23

Merge remote-tracking branch 'origin/dev' into 8-compute-dynamic-set-of-attribute-histogram-for-references # Conflicts: # evita_external_api/evita_external_api_grpc/shared/src/main/java/io/evitadb/externalApi/grpc/generated/GrpcEvitaSessionAPI.java # evita_external_api/evita_external_api_grpc/shared/src/main/java/io/evitadb/externalApi/grpc/generated/GrpcExtraResults.java # evita_external_api/evita_external_api_grpc/shared/src/main/java/io/evitadb/externalApi/grpc/generated/GrpcExtraResultsOrBuilder.java

fix: return real catalog and schema version for fresh read-only session EvitaClientSession#getCatalogVersion returned 0 on a brand-new EvitaClient that had only opened a read-only session, because the shared EvitaEntitySchemaCache had not yet been populated by any server round-trip. Zero is also a legitimate version for a warming-up catalog, so the numeric value alone cannot distinguish the two. The cache now tracks an explicit `initialized` flag that is flipped the first time a server response updates the catalog/schema versions. getCatalogVersion forces a fetchCatalogSchema round-trip when the cache is still uninitialized. GrpcCatalogSchemaResponse is extended with catalogVersion and catalogSchemaVersion so a single getCatalogSchema call populates both versions at once; the server-side EvitaSessionService fills them in. Also adds a regression test in EvitaClientReadOnlyTest that opens a fresh client and verifies the first getCatalogVersion call returns the actual server value rather than zero.

fix: return real catalog and schema version for fresh read-only session EvitaClientSession#getCatalogVersion returned 0 on a brand-new EvitaClient that had only opened a read-only session, because the shared EvitaEntitySchemaCache had not yet been populated by any server round-trip. Zero is also a legitimate version for a warming-up catalog, so the numeric value alone cannot distinguish the two. The cache now tracks an explicit `initialized` flag that is flipped the first time a server response updates the catalog/schema versions. getCatalogVersion forces a fetchCatalogSchema round-trip when the cache is still uninitialized. GrpcCatalogSchemaResponse is extended with catalogVersion and catalogSchemaVersion so a single getCatalogSchema call populates both versions at once; the server-side EvitaSessionService fills them in. Also adds a regression test in EvitaClientReadOnlyTest that opens a fresh client and verifies the first getCatalogVersion call returns the actual server value rather than zero.

2026-04-22

feat: expose name variants on HistogramIndexDefinition Extract a NamedContract super-interface from NamedSchemaContract that carries only name / name-variant methods (no description), and have HistogramIndexDefinition implement it. Variants are always server-generated via NamingConvention.generate(name) — never accepted from client input — so the mutation wire format (ScopedHistogramIndexDefinition) stays unchanged. Add ReferenceSchemaContract.getHistogramIndexDefinitionByName(scope, name, convention) returning Optional<HistogramIndexDefinition>, backed by a per-scope variant index in ReferenceSchema analogous to the reference name index on EntitySchema. Propagate the new field through the outbound surfaces: gRPC proto GrpcScopedHistogramIndexDefinition gains an output-only nameVariants field, GraphQL ReferenceSchemasBucketedDataFetcher emits variants, REST SchemaJsonSerializer serializes them, and the Kryo EntitySchemaSerializer persists them. No backward-compat serializer — the histogram feature is within-release. Ref: #8

2026-04-17

refactor: unify facet and reference summary via adapter pattern Introduce FacetSummaryAdapter, ReferenceSummaryAdapter, and ReferenceSummaryResultAdapter to share the producer pipeline between facet and reference summaries. Adds a new GraphQL FacetSummaryDataFetcher and a Functions utility, plus a backward-compatibility test for the facet summary surface. Ref: #8

2026-04-16

feat: add support for dynamic reference histograms in extra results Refs: #8

2026-04-10

Merge branch '8-compute-dynamic-set-of-attribute-histogram-for-references' into 8-compute-dynamic-set-of-attribute-histogram-for-references-extra-results # Conflicts: # evita_api/src/main/java/io/evitadb/api/requestResponse/schema/ReferenceSchemaContract.java # evita_api/src/main/java/io/evitadb/api/requestResponse/schema/ReferenceSchemaEditor.java # evita_external_api/evita_external_api_core/src/main/java/io/evitadb/externalApi/api/catalog/schemaApi/model/mutation/reference/CreateReferenceSchemaMutationDescriptor.java # evita_external_api/evita_external_api_core/src/main/java/io/evitadb/externalApi/api/catalog/schemaApi/model/mutation/reference/CreateReflectedReferenceSchemaMutationDescriptor.java # evita_query/src/main/java/io/evitadb/api/query/QueryConstraints.java

feat: ReferenceSummary extra result implementation with backward-compatibility to FacetSummary in APIs Refs: #8

Merge branch '8-compute-dynamic-set-of-attribute-histogram-for-references' into 109-distributed-database-support # Conflicts: # .gitignore # CLAUDE.md # evita_api/src/main/java/io/evitadb/api/requestResponse/schema/builder/ReferenceSchemaBuilder.java # evita_api/src/main/java/io/evitadb/api/requestResponse/schema/builder/ReflectedReferenceSchemaBuilder.java # evita_engine/src/main/java/io/evitadb/core/catalog/Catalog.java # evita_engine/src/main/java/io/evitadb/core/query/algebra/prefetch/PrefetchFormulaVisitor.java # evita_engine/src/main/java/io/evitadb/core/query/algebra/reference/ReferencedEntityIndexPrimaryKeyTranslatingFormula.java # evita_external_api/evita_external_api_grpc/shared/src/main/java/io/evitadb/externalApi/grpc/generated/GrpcEvitaDataTypes.java # evita_test/evita_functional_tests/src/test/java/io/evitadb/api/file/FileForFetchTest.java # evita_test/evita_functional_tests/src/test/java/io/evitadb/core/catalog/CatalogTest.java

2026-03-27

feat: implement conditional bucket indexing with histogram index infrastructure Introduce HistogramIndex and supporting types (SimpleHistogramIndex, LocalizedHistogramIndex, HistogramCapableEntityIndex) for dynamic attribute histogram computation on references. Refactor expression trigger system to support both facet and histogram triggers through shared AbstractExpressionIndexTrigger base. Reorganize index mutation packages (index/mutation/index → index/mutation/local) and expression trigger packages for cleaner separation of concerns. Add cross-entity trigger support via CrossEntityTriggerIndex and LocalTriggerIndex. Generalize ReevaluateExpressionMutation to handle both facet and histogram expression re-evaluation. Extract common expression operator logic into AbstractBinaryOperator and AbstractUnaryOperator base classes. Ref: #8

2026-03-23

feat: add bucketed histogram schema support for reference attributes Implement full-stack schema support for bucketed histogram indexing on reference attributes. This includes new HistogramIndexDefinition DTO, SetReferenceSchemaBucketedMutation, and updates across all 8 layers: contracts, DTOs, builders, mutations, external APIs (gRPC/GraphQL/REST), Kryo serializers, and WAL serializers. Ref: #8

2026-03-05

feat: add per-scope faceted partially configuration with expression support for references Introduce ScopedFacetedPartially record to allow configuring faceted behavior per scope with optional Expression filters. This enables dynamic attribute histogram computation for references by specifying which facet values participate in histogram aggregation. Key changes: - Add ScopedFacetedPartially to ReferenceSchemaContract and DTOs - Extract AbstractReferenceSchemaBuilder for shared builder logic - Update SetReferenceSchemaFacetedMutation to support expressions - Add support across all external APIs (gRPC, GraphQL, REST) - Add Kryo/WAL serializers with backward compatibility (2026_1) - Update skill documentation with converter serialization patterns - Restore backward compatibility for @Reference annotation Ref: #8

2026-02-23

feat: add per-scope reference indexed components configuration Introduces ScopedReferenceIndexedComponents to allow independent configuration of which reference components (entity, group, or both) are indexed in each scope. Updates reference schema contracts, builders, mutations, and all external API layers (gRPC, GraphQL, REST). Adds backward-compatible serializers for storage and WAL. Ref: #1088

2026-02-13

Merge remote-tracking branch 'refs/remotes/origin/1062-add-aggregated-crc32-checksum-to-wal-log' into 109-distributed-database-support

Merge branch 'dev' into 1062-add-aggregated-crc32-checksum-to-wal-log # Conflicts: # evita_store/evita_store_server/src/main/java/io/evitadb/store/wal/supplier/TransactionMutationWithLocation.java # evita_test/evita_functional_tests/src/test/java/io/evitadb/core/session/task/SessionKillerTest.java # evita_test/evita_functional_tests/src/test/java/io/evitadb/store/wal/CatalogWriteAheadLogIntegrationTest.java # evita_test/evita_functional_tests/src/test/java/io/evitadb/store/wal/EngineWriteAheadLogTest.java # evita_test/evita_functional_tests/src/test/java/io/evitadb/utils/StringUtilsTest.java

2026-02-11

refactor: relocate `TransactionMutation` to `mutation.infrastructure` and enhance traffic recording metadata Moved `TransactionMutation` to a new `mutation.infrastructure` package to align with package structure conventions. Added new metadata fields to traffic recording containers, such as `sessionRecordsCount`, `finishedWithError`, and `queryDescription`, and updated JavaDocs for accuracy. Fixed typos and enhanced `equals()` methods in relevant classes.

2026-02-05

refactor: Introduce streaming support for catalog backup methods - Added `backupCatalogWithProgress` and `fullBackupCatalogWithProgress` methods for streaming backup progress updates. - Implemented `BackupProgressObserver` for real-time progress handling. - Updated gRPC descriptors and service implementations to support streaming. - Modified synchronous backup methods to utilize the newly implemented streaming capabilities. - Adjusted error handling for better resilience against interruptions and server-side errors.

2026-01-26

refactor: replace EvitaInternalError with specific exceptions and enhance histogram logic Replaced `EvitaInternalError` with more specific exception types (`EvitaInvalidUsageException`, `GenericEvitaInternalError`, etc.) for better error handling and clarity. Improved `relativeFrequency` normalization logic for equalized histograms and updated associated Javadoc, tests, and documentation. Refs: #762 Signed-off-by: Jan Novotný <novotnaci@gmail.com>

2026-01-25

feat: add relative frequency calculations for histogram buckets Introduced `relativeFrequency` field for histogram buckets to enhance UI visualization. Implemented calculation support for both standard and equalized histograms in data crunchers, API descriptors, and serialization layers. Refs: #762 Signed-off-by: Jan Novotný <novotnaci@gmail.com>

2026-01-23

feat: Introduce alternative calculation for histograms There is a more UX-friendly version of histogram calculations documented here: https://www.howdoi.me/blog/slider-scale.html, which is also discussed in more detail in the article https://baymard.com/blog/slider-interfaces ... we are discussing its support in the team. Refs: #762 Signed-off-by: Jan Novotný <novotnaci@gmail.com>

2026-01-09

Merge branch 'refs/heads/dev' into 109-distributed-database-support

fix: Subscription should be kept alive The subscriptions gets closed after certain time of inactivity (can be configured), but it would be much better if the server regurarly sent heartbeet messages in regular intervals over the connection so that it never time out. Also we found out that when subscription is recreated from close method of the previous subscriber it doesn't work probably due to the fact that it's handled in a shared thread which received signal of subscription drop. We should invoke delegate subscribe methods asynchronously in separate executor to avoid this problem. Refs: #1057 Signed-off-by: Jan Novotný <novotnaci@gmail.com>

2025-12-26

feat: automatic backup to S3 Distinguishing files that will be managed by outside logic (backup retention) rather than internal export service retention logic. Refs: #1000

2025-12-18

feat: automatic backup to S3 Added checksum calculation. Refs: #1000

2025-12-10

feat: added timestamp field to all change capture events Timestamp comes handy when only local mutation is result of the predicate filter.

fix: fixed date range CDC localization

2025-11-19

Merge branch 'dev' into 977-support-filtering-schema-captures-by-containername # Conflicts: # evita_engine/src/main/java/io/evitadb/core/Catalog.java # evita_external_api/evita_external_api_core/src/main/java/io/evitadb/externalApi/api/catalog/schemaApi/model/mutation/catalog/CreateEntitySchemaMutationDescriptor.java # evita_external_api/evita_external_api_core/src/main/java/io/evitadb/externalApi/api/catalog/schemaApi/model/mutation/catalog/ModifyEntitySchemaMutationDescriptor.java # evita_external_api/evita_external_api_graphql/src/main/java/io/evitadb/externalApi/graphql/api/catalog/schemaApi/builder/EntitySchemaSchemaBuilder.java # evita_external_api/evita_external_api_grpc/shared/src/main/java/io/evitadb/externalApi/grpc/generated/EvitaSessionServiceGrpc.java # evita_external_api/evita_external_api_grpc/shared/src/main/java/io/evitadb/externalApi/grpc/generated/GrpcEvitaSessionAPI.java # evita_functional_tests/src/test/java/io/evitadb/api/EvitaTransactionalFunctionalTest.java # evita_functional_tests/src/test/java/io/evitadb/externalApi/api/catalog/schemaApi/resolver/mutation/DelegatingLocalCatalogSchemaMutationConverterTest.java # evita_functional_tests/src/test/java/io/evitadb/externalApi/api/catalog/schemaApi/resolver/mutation/LocalCatalogSchemaMutationInputAggregateConverterTest.java # evita_functional_tests/src/test/java/io/evitadb/externalApi/api/catalog/schemaApi/resolver/mutation/engine/ModifyCatalogSchemaMutationConverterTest.java # evita_functional_tests/src/test/java/io/evitadb/externalApi/graphql/api/catalog/schemaApi/CatalogGraphQLUpdateCatalogSchemaQueryFunctionalTest.java # evita_store/evita_store_server/src/main/java/io/evitadb/store/catalog/DefaultCatalogPersistenceService.java

2025-10-31

doc: documented entity mutations Signed-off-by: Jan Novotný <novotnaci@gmail.com>

2025-10-21

fix: It's not possible to store detached builder instances on client side Issue is documented and reproducible by tests: - io.evitadb.api.proxy.EntityEditorProxyingFunctionalTest#shouldSetReferenceGroupAsNewlyCreatedEntity - io.evitadb.api.proxy.EntityEditorProxyingFunctionalTest#shouldSetReferenceGroupByIdAndUpdateIt The root cause is that the client works with locally assigned primary keys for reference keys, which are rewritten by primary keys assigned on the server side (final primary keys). This information is not propagated to the client though (there is no way actually). We need to be able to propagate this information via. gRPC API to the client so that it could replace its former internal PKs with real PKs from the server side and continue working (and sending updates back to the server) with the correct primary keys. In order to do that we need to apply backward incompatible change on `EvitaSessionContract` level - instead of using `EntityReference` records in the methods, we need to stick to common interface `EntityReferenceContract`. This may break some clients though. Refs: #979 Signed-off-by: Jan Novotný <novotnaci@gmail.com>

2025-10-20

feat: Support filtering schema captures by containerName Team has agreed that it makes sense to filter schema mutations by containerName in the similar fashion as data captures. Because of evitaLab view we also need to create new method for acquiring transactional mutations by the set of catalogVersions. Refs: #977 Signed-off-by: Jan Novotný <novotnaci@gmail.com>

2025-10-17

feat: Support filtering schema captures by containerName Team has agreed that it makes sense to filter schema mutations by containerName in the similar fashion as data captures. Refs: #977 Signed-off-by: Jan Novotný <novotnaci@gmail.com>

2025-10-02

feat: Support for multiple references to the same entity with different attribute sets Added missing internal PK in gRPC communication. Refs: #906 Signed-off-by: Jan Novotný <novotnaci@gmail.com>

2025-09-23

Merge branch 'dev' into 906-support-for-multiple-references-to-the-same-entity-with-different-attribute-sets

feat: support for filtering stream by date and time range

Merge branch 'dev' into 906-support-for-multiple-references-to-the-same-entity-with-different-attribute-sets # Conflicts: # evita_functional_tests/src/test/java/io/evitadb/core/cdc/CatalogChangeObserverTest.java

2025-09-19

fix: added missing transaction mutation body

2025-09-16

Merge branch 'dev' into 906-support-for-multiple-references-to-the-same-entity-with-different-attribute-sets # Conflicts: # evita_external_api/evita_external_api_grpc/shared/src/main/java/io/evitadb/externalApi/grpc/generated/GrpcEntityReference.java # evita_external_api/evita_external_api_grpc/shared/src/main/java/io/evitadb/externalApi/grpc/generated/GrpcReference.java # evita_external_api/evita_external_api_grpc/shared/src/main/java/io/evitadb/externalApi/grpc/generated/GrpcReferenceAttributeMutation.java # evita_external_api/evita_external_api_grpc/shared/src/main/java/io/evitadb/externalApi/grpc/generated/GrpcReferenceOrBuilder.java # evita_external_api/evita_external_api_grpc/shared/src/main/java/io/evitadb/externalApi/grpc/generated/GrpcRemoveReferenceGroupMutation.java # evita_external_api/evita_external_api_grpc/shared/src/main/java/io/evitadb/externalApi/grpc/generated/GrpcRemoveReferenceMutation.java # evita_external_api/evita_external_api_grpc/shared/src/main/java/io/evitadb/externalApi/grpc/generated/GrpcSetReferenceGroupMutation.java

fix: fixed mutation listing Corrected CDC index calculation and handling in gRPC. Disabling session kills in `run-server.sh` so that we can test gRPC API more easily.

fix: fixed mutation listing Upgraded gRPC version to valid one. Corrected ModifyEntitySchema conversion. Fixed problem on client side that attempted to remove non-existing catalog.

2025-09-15

feat: Support for multiple references to the same entity with different attribute sets Indexing index primary keys instead of referenced entity keys to ReferencedTypeEntityIndex done with all tests passing except known issues that will be handled later. Refs: #906 Signed-off-by: Jan Novotný <novotnaci@gmail.com>

2025-08-29

feat: Support for multiple references to the same entity with different attribute sets Clients encountered situations in which they needed to declare multiple items to the same entity within a single reference. For example, there is a reference to "media" with two references to media ID = 5. The reason is that the references are further distinguished by related attributes, for example: a reference to ID = 5, attribute "category" = "motive," attribute "order" = 1 a reference to ID 5 with the category attribute set to "motive" and the order attribute set to 1 a reference to ID 6 with the category attribute set to "gallery" and the order attribute set to 2 In these cases, the user wants to filter by the category attribute and sort by the order attribute. This case is currently not supported by evitaDB. Refs: #906 Signed-off-by: Jan Novotný <novotnaci@gmail.com>

2025-07-24

Merge branch 'dev' into 187-different-api-proposal # Conflicts: # evita_api/src/main/java/io/evitadb/api/requestResponse/schema/builder/AbstractAttributeSchemaBuilder.java # evita_api/src/main/java/io/evitadb/api/requestResponse/schema/builder/ReferenceSchemaBuilder.java # evita_api/src/main/java/io/evitadb/api/requestResponse/schema/builder/ReflectedReferenceSchemaBuilder.java # evita_api/src/main/java/io/evitadb/api/requestResponse/schema/mutation/reference/CreateReferenceSchemaMutation.java # evita_api/src/main/java/io/evitadb/api/requestResponse/schema/mutation/reference/SetReferenceSchemaIndexedMutation.java # evita_engine/src/main/java/io/evitadb/core/query/indexSelection/TargetIndexes.java # evita_engine/src/main/java/io/evitadb/index/EntityIndex.java # evita_engine/src/main/java/io/evitadb/index/ReferencedTypeEntityIndex.java # evita_engine/src/main/java/io/evitadb/index/mutation/index/EntityIndexLocalMutationExecutor.java # evita_external_api/evita_external_api_core/src/main/java/io/evitadb/externalApi/api/catalog/schemaApi/resolver/mutation/reference/CreateReferenceSchemaMutationConverter.java # evita_external_api/evita_external_api_core/src/main/java/io/evitadb/externalApi/api/catalog/schemaApi/resolver/mutation/reference/CreateReflectedReferenceSchemaMutationConverter.java # evita_external_api/evita_external_api_core/src/main/java/io/evitadb/externalApi/api/catalog/schemaApi/resolver/mutation/reference/SetReferenceSchemaIndexedMutationConverter.java # evita_external_api/evita_external_api_graphql/src/main/java/io/evitadb/externalApi/graphql/api/catalog/schemaApi/builder/EntitySchemaSchemaBuilder.java # evita_external_api/evita_external_api_grpc/shared/src/main/java/io/evitadb/externalApi/grpc/generated/GrpcEnums.java # evita_external_api/evita_external_api_grpc/shared/src/main/java/io/evitadb/externalApi/grpc/generated/GrpcEvitaManagementAPI.java # evita_external_api/evita_external_api_grpc/shared/src/main/java/io/evitadb/externalApi/grpc/requestResponse/schema/EntitySchemaConverter.java # evita_external_api/evita_external_api_rest/src/main/java/io/evitadb/externalApi/rest/api/catalog/schemaApi/builder/EntitySchemaObjectBuilder.java # evita_functional_tests/src/test/java/io/evitadb/api/EvitaSchemaCallbackTest.java # evita_functional_tests/src/test/java/io/evitadb/api/EvitaTest.java # evita_functional_tests/src/test/java/io/evitadb/api/functional/hierarchy/AbstractHierarchyTest.java # evita_functional_tests/src/test/java/io/evitadb/api/proxy/mock/AbstractCategoryPojo.java # evita_functional_tests/src/test/java/io/evitadb/api/proxy/mock/AbstractProductCategoryPojo.java # evita_functional_tests/src/test/java/io/evitadb/api/proxy/mock/BrandInterface.java # evita_functional_tests/src/test/java/io/evitadb/api/proxy/mock/BrandInterfaceEditor.java # evita_functional_tests/src/test/java/io/evitadb/api/proxy/mock/CategoryInterface.java # evita_functional_tests/src/test/java/io/evitadb/api/proxy/mock/CategoryInterfaceEditor.java # evita_functional_tests/src/test/java/io/evitadb/api/proxy/mock/CategoryInterfaceSealed.java # evita_functional_tests/src/test/java/io/evitadb/api/proxy/mock/CategoryPojo.java # evita_functional_tests/src/test/java/io/evitadb/api/proxy/mock/CategoryRecord.java # evita_functional_tests/src/test/java/io/evitadb/api/proxy/mock/EmptyEntitySchemaAccessor.java # evita_functional_tests/src/test/java/io/evitadb/api/proxy/mock/FinalProductPojo.java # evita_functional_tests/src/test/java/io/evitadb/api/proxy/mock/MockCatalogChangeCaptureSubscriber.java # evita_functional_tests/src/test/java/io/evitadb/api/proxy/mock/MockCatalogStructuralChangeObserver.java # evita_functional_tests/src/test/java/io/evitadb/api/proxy/mock/MockEngineChangeCaptureSubscriber.java # evita_functional_tests/src/test/java/io/evitadb/api/proxy/mock/ParameterGroupInterfaceEditor.java # evita_functional_tests/src/test/java/io/evitadb/api/proxy/mock/ParameterInterface.java # evita_functional_tests/src/test/java/io/evitadb/api/proxy/mock/ParameterInterfaceEditor.java # evita_functional_tests/src/test/java/io/evitadb/api/proxy/mock/ProductCategoryInterface.java # evita_functional_tests/src/test/java/io/evitadb/api/proxy/mock/ProductCategoryInterfaceEditor.java # evita_functional_tests/src/test/java/io/evitadb/api/proxy/mock/ProductCategoryPojo.java # evita_functional_tests/src/test/java/io/evitadb/api/proxy/mock/ProductCategoryRecord.java # evita_functional_tests/src/test/java/io/evitadb/api/proxy/mock/ProductInterfaceSealed.java # evita_functional_tests/src/test/java/io/evitadb/api/proxy/mock/ProductParameterInterface.java # evita_functional_tests/src/test/java/io/evitadb/api/proxy/mock/ProductParameterInterfaceEditor.java # evita_functional_tests/src/test/java/io/evitadb/api/proxy/mock/ProductPojo.java # evita_functional_tests/src/test/java/io/evitadb/api/proxy/mock/ProductRecord.java # evita_functional_tests/src/test/java/io/evitadb/api/proxy/mock/SealedProductInterface.java # evita_functional_tests/src/test/java/io/evitadb/api/proxy/mock/SealedProductPojo.java # evita_functional_tests/src/test/java/io/evitadb/api/proxy/mock/StoreInterface.java # evita_functional_tests/src/test/java/io/evitadb/api/proxy/mock/StoreInterfaceEditor.java # evita_functional_tests/src/test/java/io/evitadb/api/proxy/mock/TestEntity.java # evita_functional_tests/src/test/java/io/evitadb/api/proxy/mock/UnknownEntityEditorInterface.java # evita_functional_tests/src/test/java/io/evitadb/api/proxy/mock/UnknownEntityInterface.java # evita_functional_tests/src/test/java/io/evitadb/api/requestResponse/data/structure/AbstractBuilderTest.java # evita_functional_tests/src/test/java/io/evitadb/api/requestResponse/schema/CatalogSchemaBuilderTest.java # evita_functional_tests/src/test/java/io/evitadb/api/requestResponse/schema/ClassSchemaAnalyzerTest.java # evita_functional_tests/src/test/java/io/evitadb/api/requestResponse/schema/EntitySchemaBuilderTest.java # evita_functional_tests/src/test/java/io/evitadb/api/requestResponse/schema/model/FieldBasedEntityWithNonDefaults.java # evita_functional_tests/src/test/java/io/evitadb/api/requestResponse/schema/model/GetterBasedEntityWithNonDefaults.java # evita_functional_tests/src/test/java/io/evitadb/api/requestResponse/schema/model/RecordBasedEntityWithNonDefaults.java # evita_functional_tests/src/test/java/io/evitadb/core/file/ExportFileServiceTest.java # evita_functional_tests/src/test/java/io/evitadb/documentation/mock/Product.java # evita_functional_tests/src/test/java/io/evitadb/driver/EvitaClientReadWriteTest.java # evita_functional_tests/src/test/java/io/evitadb/externalApi/grpc/builders/query/extraResults/GrpcHierarchyBuilderTest.java # evita_functional_tests/src/test/java/io/evitadb/index/mutation/AttributeIndexMutatorTest.java # evita_functional_tests/src/test/java/io/evitadb/index/mutation/ReferenceIndexMutatorTest.java # evita_functional_tests/src/test/java/io/evitadb/index/price/PriceSuperIndexTest.java # evita_functional_tests/src/test/java/io/evitadb/store/offsetIndex/OffsetIndexTest.java # evita_store/evita_store_key_value/src/main/java/io/evitadb/store/offsetIndex/model/StorageRecord.java # evita_store/evita_store_server/src/main/resources/META-INF/services/io.evitadb.store.spi.EnginePersistenceServiceFactory # evita_test_support/src/main/java/io/evitadb/test/client/query/rest/RestQueryConverter.java # evita_test_support/src/main/java/io/evitadb/test/extension/EvitaParameterResolver.java

feat: Change Data Capture support Corrected documentation. Refs: #187

Merge branch 'dev' into 920-introduce-more-granular-control-over-reduced-indexes-in-reference-schema

2025-07-23

feat: Change Data Capture support Made optional fields really optional. Propagation of read-only flag to catalog. Refs: #187

feat: support for multiple origins in file listing Minor enhancement to gRPC API for fetching files. Now listing may return files from multiple origins at once.

2025-07-21

feat: Introduce more granular control over reduced indexes in reference schema We realized that many secondary - ReducedEntityIndexes may not be necessary and propose to add better granularity to reference schema `indexed` property. Currently it could be only true / false and tied to particular scope. This setting then leads to creating ReducedEntityIndex for each of the reference. This might lead to explosion of indexed (in combination with reflected schemas). In fact we need to distinguish two situations: 1. we need the indexed=true for ability to issue filters like `referenceHaving` 2. we need the indexed=true to shard the data of the original entity and gain a considerable performance benefit when applying filters/sort over the main entity In many cases we just need the scenario 1. and this cannot be stated in the schema currently. So the proposal is tu change indexed to enum of two possible values (similar to enums in unique property): - FOR_FILTERING - FOR_FILTERING_AND_PARTITIONING The second will maintain the current behavior. The first will just maintain ReducedTypeIndex, but no ReducedIndexes for all possible references. This may bring considerable memory savings and speeding up indexing process. Refs: #920

2025-07-18

feat: Top level (engine) WAL Duplicating logic done on the client side and tested. Refs: #502

feat: Top level (engine) WAL Restore now creates only inactive catalog. Added partial catalog duplication logic. Refs: #502

feat: Top level (engine) WAL Added progress method variants for rename and replace catalog. Refs: #502

feat: Top level (engine) WAL Accessing progress of engine mutations in flight via gRPC protocol Refs: #502

2025-07-17

feat: Top level (engine) WAL Added mutability per catalog support on client side with tests. Refs: #502

feat: Top level (engine) WAL Catalog loading is now fully asynchronous and parallel - this speeds up start process on machines with multiple CPUs. Refs: #502

2025-07-14

fix: attempt to correct timeouts in goLive method

feat: GoLive needs to be changed to asynchronous operations Unified all engine mutations to be asynchronous and progressive. Corrected tests. Refs: #910

2025-07-09

Merge branch 'refs/heads/dev' into 187-different-api-proposal # Conflicts: # evita_engine/src/main/java/io/evitadb/core/Evita.java # evita_engine/src/main/java/io/evitadb/core/EvitaSession.java # evita_external_api/evita_external_api_grpc/shared/src/main/java/io/evitadb/externalApi/grpc/generated/GrpcEvitaSessionAPI.java # evita_functional_tests/src/test/java/io/evitadb/driver/EvitaClientReadWriteTest.java # evita_query/src/main/java/io/evitadb/api/query/expression/parser/grammar/ExpressionLexer.java # evita_query/src/main/java/io/evitadb/api/query/expression/parser/grammar/ExpressionParser.java # pom.xml

fix: error during closing session after goLive operation via gRPC

fix: error during closing session after goLive operation via gRPC

fix: error during closing session after goLive operation via gRPC

2025-07-08

Merge branch 'dev' into 187-different-api-proposal # Conflicts: # evita_api/src/main/java/io/evitadb/api/CatalogContract.java # evita_engine/src/main/java/io/evitadb/core/Catalog.java # evita_engine/src/main/java/io/evitadb/core/CorruptedCatalog.java # evita_engine/src/main/java/io/evitadb/core/Evita.java # evita_engine/src/main/java/io/evitadb/core/EvitaSession.java # evita_engine/src/main/java/io/evitadb/core/buffer/DataStoreChanges.java # evita_engine/src/main/java/io/evitadb/core/executor/ProgressingFuture.java # evita_engine/src/main/java/io/evitadb/index/CatalogIndex.java # evita_engine/src/main/java/io/evitadb/index/EntityIndex.java # evita_engine/src/main/java/io/evitadb/index/Index.java # evita_engine/src/main/java/io/evitadb/store/spi/PersistenceService.java # evita_external_api/evita_external_api_graphql/src/main/java/io/evitadb/externalApi/graphql/api/system/resolver/mutatingDataFetcher/SwitchCatalogToAliveStateMutatingDataFetcher.java # evita_external_api/evita_external_api_grpc/server/src/main/java/io/evitadb/externalApi/grpc/services/EvitaSessionService.java # evita_external_api/evita_external_api_grpc/shared/src/main/java/io/evitadb/externalApi/grpc/generated/EvitaSessionServiceGrpc.java # evita_external_api/evita_external_api_grpc/shared/src/main/java/io/evitadb/externalApi/grpc/generated/GrpcEvitaSessionAPI.java # evita_external_api/evita_external_api_rest/src/main/java/io/evitadb/externalApi/rest/api/system/resolver/endpoint/UpdateCatalogHandler.java # evita_functional_tests/src/test/java/io/evitadb/index/facet/FacetIndexTest.java # evita_functional_tests/src/test/java/io/evitadb/index/mutation/AttributeIndexMutatorTest.java # evita_store/evita_store_server/src/main/java/io/evitadb/store/catalog/DefaultCatalogPersistenceService.java # evita_store/evita_store_server/src/main/java/io/evitadb/store/catalog/DefaultEntityCollectionPersistenceService.java

feat: GoLive needs to be changed to asynchronous operations It could take considerable amount of time if it is combined with large session performing big data insertion. It needs to behave the same way as asynchronous close (because it does the goLiveAndClose - so it inherently closes sessions). At the end of the session the flush is performed which may wait for flushing all data to the disk. Refs: #910

2025-07-01

feat: Change Data Capture support Client subscriptions implemented. Refs: #187

2025-06-20

feat: Change Data Capture support Client subscriptions implemented (not tested). Refs: #187

feat: Change Data Capture support Client subscriptions implemented (not tested). Refs: #187

2025-06-18

feat: Change Data Capture support gRPC implementation done (not tested). Refs: #187

feat: Change Data Capture support Evita class refactoring - dirty work finished. Refs: #187

2025-06-17

feat: Change Data Capture support Evita class refactoring - dirty work finished. Refs: #187

2025-06-10

Merge branch 'dev' into 187-different-api-proposal # Conflicts: # evita_api/src/main/java/io/evitadb/api/requestResponse/EvitaRequest.java # evita_api/src/main/java/io/evitadb/api/requestResponse/data/PricesContract.java # evita_engine/src/main/java/io/evitadb/core/query/sort/price/translator/PriceDiscountTranslator.java # evita_external_api/evita_external_api_graphql/src/main/java/io/evitadb/externalApi/graphql/api/catalog/dataApi/CatalogDataApiGraphQLSchemaBuilder.java # evita_external_api/evita_external_api_graphql/src/main/java/io/evitadb/externalApi/graphql/api/catalog/dataApi/builder/CollectionGraphQLSchemaBuildingContext.java # evita_external_api/evita_external_api_graphql/src/main/java/io/evitadb/externalApi/graphql/api/catalog/dataApi/resolver/dataFetcher/ListEntitiesDataFetcher.java # evita_external_api/evita_external_api_graphql/src/main/java/io/evitadb/externalApi/graphql/api/catalog/dataApi/resolver/dataFetcher/entity/AbstractPriceForSaleDataFetcher.java # evita_external_api/evita_external_api_graphql/src/main/java/io/evitadb/externalApi/graphql/api/catalog/dataApi/resolver/dataFetcher/entity/AccompanyingPriceDataFetcher.java # evita_external_api/evita_external_api_graphql/src/main/java/io/evitadb/externalApi/graphql/api/catalog/dataApi/resolver/dataFetcher/entity/AttributeValueDataFetcher.java # evita_external_api/evita_external_api_graphql/src/main/java/io/evitadb/externalApi/graphql/api/catalog/dataApi/resolver/dataFetcher/entity/AttributesDataFetcher.java # evita_functional_tests/src/test/java/io/evitadb/api/requestResponse/data/structure/predicate/PriceContractSerializablePredicateTest.java # evita_store/evita_store_server/src/main/java/io/evitadb/store/query/serializer/filter/PriceInPriceListsSerializer.java

feat: Change Data Capture support Evita class refactoring. Refs: #187

2025-06-09

Merge pull request #900 from FgForrest/895-default-accompanying-price feat: Default accompanying price

feat: Default accompanying price Frontend developers want to avoid argument specification on `accompanyingPrice` field. One possible solution is to create a new reuirement: ```graphql require: { accompaniedPrice: ["reference", "basic"] } ``` Which would allow to specify "default" price list and their priorities for using `accompaniedPrice` in the fetch part of the query like this: ```graphql priceForSale { priceWithTax priceWithoutTax currency validity accompanyingPrice { priceWithTax priceWithoutTax currency validity } } ``` Refs: #895

2025-06-06

Merge branch 'dev' into 187-different-api-proposal # Conflicts: # evita_external_api/evita_external_api_graphql/src/main/java/io/evitadb/externalApi/graphql/api/catalog/dataApi/resolver/constraint/FacetSummaryResolver.java # evita_external_api/evita_external_api_graphql/src/main/java/io/evitadb/externalApi/graphql/api/catalog/dataApi/resolver/dataFetcher/QueryEntitiesDataFetcher.java # evita_external_api/evita_external_api_grpc/shared/src/main/java/io/evitadb/externalApi/grpc/generated/EvitaSessionServiceGrpc.java # evita_external_api/evita_external_api_grpc/shared/src/main/java/io/evitadb/externalApi/grpc/generated/GrpcEvitaSessionAPI.java # evita_functional_tests/src/test/java/io/evitadb/externalApi/rest/api/catalog/dataApi/CatalogRestQueryEntityQueryFunctionalTest.java # evita_query/src/main/java/io/evitadb/api/query/descriptor/ConstraintDescriptorProvider.java # evita_store/evita_store_key_value/src/main/java/io/evitadb/store/offsetIndex/io/OffHeapMemoryOutputStream.java

2025-06-02

feat: Full backup Currently we support active and snapshot (PIT) backups. We also need to support "full" backup, that backs up all contents of the catalog directory that contain all data necessary for making PIT backups after restoring (i.e. is lossless). This type of backup should be used in system backups. Refs: #892

2025-05-21

Merge branch 'dev' into 187-different-api-proposal # Conflicts: # evita_api/src/main/java/io/evitadb/api/EvitaContract.java # evita_engine/src/main/java/io/evitadb/core/Catalog.java # evita_engine/src/main/java/io/evitadb/core/Evita.java # evita_engine/src/main/java/io/evitadb/core/transaction/TransactionManager.java # evita_external_api/evita_external_api_grpc/shared/src/main/java/io/evitadb/externalApi/grpc/generated/EvitaSessionServiceGrpc.java # evita_external_api/evita_external_api_grpc/shared/src/main/java/io/evitadb/externalApi/grpc/generated/GrpcEnums.java # evita_external_api/evita_external_api_grpc/shared/src/main/java/io/evitadb/externalApi/grpc/generated/GrpcEvitaSessionAPI.java # evita_functional_tests/src/test/java/io/evitadb/api/EvitaTest.java # evita_store/evita_store_key_value/src/main/java/io/evitadb/store/offsetIndex/exception/CorruptedRecordException.java

feat: Change Data Capture support New publisher implementation with tests. Refs: #187

2025-05-18

feat!: Propagate catalog schema version to client Renamed commit behavior to more understandable name. BREAKING-CHANGE: Commit behavior `WAIT_FOR_INDEX_PROPAGATION` renamed to `WAIT_FOR_CHANGES_VISIBLE`

2025-05-16

feat!: Propagate catalog schema version to client As for now the catalog schema on the client side is invalidate regurarly on obsolete checks and doesn't immediatelly detect catalog schema changes executed by different clients. We should return current catalog schema version at the close session method and similar places so that the client can immediatelly detect and invalidate the catalog schema. BREAKING-CHANGE: `CompletableFuture` in `EvitaContract` and `EvitaSessionContract` were replaced with `CompletionStage`, which is read-only (intended) and can be easily converted to `CompletableFuture`.

2025-05-06

Merge remote-tracking branch 'origin/dev' into 187-different-api-proposal # Conflicts: # evita_engine/src/main/java/io/evitadb/core/Evita.java # evita_external_api/evita_external_api_grpc/server/src/main/java/io/evitadb/externalApi/grpc/services/EvitaService.java # evita_external_api/evita_external_api_grpc/shared/src/main/java/io/evitadb/externalApi/grpc/generated/EvitaServiceGrpc.java # evita_external_api/evita_external_api_grpc/shared/src/main/java/io/evitadb/externalApi/grpc/generated/GrpcEnums.java # evita_external_api/evita_external_api_grpc/shared/src/main/java/io/evitadb/externalApi/grpc/generated/GrpcEvitaAPI.java # evita_functional_tests/src/test/java/io/evitadb/store/dataType/serializer/SerialVersionBasedSerializerTest.java # evita_store/evita_store_common/src/main/java/io/evitadb/store/dataType/serializer/SerialVersionBasedSerializer.java # evita_store/evita_store_common/src/main/java/io/evitadb/store/exception/StoredVersionNotSupportedException.java