Get desktop application:
View/edit binary Protocol Buffers messages
This service contains RPCs that could be called by gRPC clients on evitaDB. Main purpose of this service is to provide a way to create sessions and catalogs, and to update the catalog.
Procedure used to list the indexes of one entity collection, or the ones a catalog holds itself, a page at a time. Where the index summary reported by `GetEntityCollectionStatisticsSnapshot` counts indexes by type and scope, this enumerates them individually - the drill-down that follows an alarming count. Which owner is listed is chosen by `GrpcIndexBrowseRequest.entityType`; both answer with the same rows. Never poll the collection form. Every call walks the collection's whole index map, unavoidably: there is no per-type index of the indexes to consult, and building one would duplicate every key while still costing a full pass to order. Filters and ordering change the constant, not the growth, and paging keeps the answer small rather than the work behind it. The catalog form is bounded by the number of scopes and carries none of that cost.
Request for one page of the indexes held by one entity collection, or of those the catalog holds itself. Filters are conjunctive across categories and disjunctive within one: an index must match every non-empty category, and matches a category by being any one of its values. An empty repeated field means that category does not filter - never that nothing matches.
Name of the catalog holding the indexes. A catalog the server does not know is an error.
Name of the entity collection whose indexes to browse, i.e. its entity type. A collection the catalog does not hold is an error, not an empty page - an empty page would be indistinguishable from a collection holding no indexes. Unset browses the indexes the catalog holds itself - the globally-unique attribute index there is one of per scope - rather than any collection's. Both forms answer with the same rows under the same filters; a catalog index carries no type and no reference, so `indexTypes` and `referenceNames` below select none of them.
Page of the result to return. Page-based paging: 1-indexed, page 1 is the first page (see `io.evitadb.dataType.PaginatedList#getPageNumber`). A page past the end returns no indexes and is not an error. Every ordering except `INDEX_BROWSE_ORDERING_MAP_ORDER` additionally limits how deep it may be paged, in either direction: `pageNumber * pageSize` must not exceed 10000, and a request beyond that is rejected rather than clamped. Those orderings rank their candidates, so producing a page means retaining every index up to the end of it - a far-out page would retain and sort the whole index set only to answer with an empty page, and it would do so whichever end the page is cut from. Map order carries no such limit, because it materialises only the requested window however deep that window sits.
Number of indexes per page. Must be between 1 and 1000; a larger value is rejected rather than clamped, because a clamped page is indistinguishable from a complete one and a client paging until it sees a short page would stop early believing it had seen everything. This surface enforces a maximum where `GrpcTaskStatusesRequest` does not: task counts are small, index counts are not, and the cost of a ranked walk is bounded by `pageNumber * pageSize`, both of which the client chooses.
What to rank the indexes by before the page is cut. Unset means `INDEX_BROWSE_ORDERING_MAP_ORDER`, the walk of the whole set in the map's own order - the cheapest answer, and the only one that carries no ranking a client could mistake for one it asked for.
Which end of that ranking the page is cut from: `DESC` for the biggest, busiest or most-maintained indexes, `ASC` for the smallest and the untouched ones. Unset means `ASC`. `INDEX_BROWSE_ORDERING_MAP_ORDER` is the one ordering that constrains this. It ranks nothing, so it has nothing to reverse: it is accepted with `ASC` alone - which is how "the map's own walk order" is spelled - and a request pairing it with `DESC` is rejected rather than answered with the forward walk, because a direction that was silently ignored reads back to the client as one that was honoured. Every other ordering accepts both.
Index types to keep; an index matches if its type is any of the listed values. Empty (the default) keeps every type.
Scopes to keep; an index matches if its scope is any of the listed values. Empty (the default) keeps both scopes.
Names of the references whose indexes to keep. Empty (the default) keeps indexes regardless of reference. Naming a reference the entity schema does not declare is an error rather than an empty page, so that a typo cannot read as "this reference has no indexes". Note that global indexes are bound to no reference and therefore never satisfy this filter. A catalog browse - one with `entityType` unset - has no entity schema to validate these against, and answers any non-empty list with an empty page rather than an error: catalog indexes have no reference dimension at all, so there is no typo to be protected from.
Response carrying one page of an index browse.
Version of the catalog this page was read at. Compare it across the pages of one browse: the index set moves as data is written, and two pages read at different versions do not describe one set. Unlike two disagreeing statistics snapshots, which are merely stale, two disagreeing pages corrupt the client's picture of what exists. That comparison only discriminates once the catalog is alive. The version advances per committed transaction, and a warming-up catalog runs no transactions - so during a bulk load it stays put while the index set churns faster than at any other time, and pages that differ can report the same version. Each page is still internally consistent regardless: warm-up costs cross-page comparison, never within-page coherence.
The page that was returned, 1-indexed, echoing the request.
The page size that was applied, echoing the request.
How many indexes matched the filters in total, across every page (indexes). Not the number returned in this page, and not the collection's total index count unless the browse was unfiltered.
The indexes on this page, in the requested order. Shorter than `pageSize` on the last page, and empty when `pageNumber` addresses a page past the end.
Procedure used to cancel queued or running task.
Request to cancel a task by id
Identification of the task
Response to a cancel task request.
True if a task with the given id existed and was successfully canceled; false if no such task exists, or the task could no longer be canceled (e.g. it had already finished).
Procedure used to delete file contents
Request to delete a file available for fetching, by its id.
Identification of the file
Response to a file deletion request.
True if the file existed and was deleted; false if no file exists for the given id. Any other failure during deletion is reported as a gRPC error rather than `false`.
Procedure used to get file contents, streamed back to the client in chunks.
Request to stream the contents of a single file available for fetching, by its id.
Identification of the file
One chunk of a file's contents, streamed back to the client. The server sends a sequence of these messages; concatenate `fileContents` from all of them, in arrival order, to reconstruct the full file.
One chunk of the file's binary contents.
Total size of the complete file (bytes); the same value is repeated on every chunk in the stream, not just the size of this chunk.
Procedure used to obtain component-selected statistics snapshots of every catalog known to the server, ordered by catalog name. The component-selected replacement for the deprecated `GetCatalogStatistics`.
Request for component-selected statistics snapshots of every catalog known to the server. Replaces the deprecated `GetCatalogStatistics` procedure, which always computed everything for everyone.
The components to compute for each catalog. The same rules as for a single catalog apply: a component with no catalog-level form cannot be requested here, and so its cost can never be multiplied by the number of catalogs. Everything returned here *is* multiplied by the catalog count, so components are weighed on payload as well as on compute time; `COMPONENT_INDEX_CARDINALITY` is allowed because the listing it reports at the catalog level is a handful of `O(1)` counter readings, staying in the same size class as the collection inventory of `COMPONENT_COLLECTIONS`. Selection is opt-in - a client that cannot afford a component simply does not name it.
Response carrying one component-selected statistics snapshot per catalog.
Statistics of every catalog known to the server, ordered by catalog name, corrupted catalogs included.
Deprecated since 2026.3 - superseded by `GetAllCatalogStatisticsSnapshots`, and by `GetCatalogStatisticsSnapshot` / `GetEntityCollectionStatisticsSnapshot` when a single catalog or collection is wanted. This one computes every statistic of every catalog on every call and returns them in a fixed flat shape whose size grows with the number of entity collections, it cannot report *why* a figure is missing (an unknown value is indistinguishable from a real `-1`), and it offers no way to ask for one catalog or one collection. Its semantics are frozen and will not change while it remains.
Response to a server catalog statistics request.
Per-catalog statistics for every catalog known to the server, including corrupted ones (see `GrpcCatalogStatistics.unusable`, where most other fields fall back to a placeholder value).
Procedure used to obtain a component-selected statistics snapshot of one named catalog. The client names the components it needs and the server computes only those, so a polled management screen pays for what it displays.
Request for a component-selected statistics snapshot of one named catalog.
Name of the catalog to describe. A catalog the server does not know is an error, not an empty response.
The components to compute. Every one of them must have a catalog-level form; every component defined today does, so what this rejects in practice is `COMPONENT_UNSPECIFIED` and an empty list. `COMPONENT_IDENTITY` is delivered whether or not it appears here. `COMPONENT_INDEX_CARDINALITY` is accepted, but note it describes the catalog index's global unique indexes here, not the collections' own entity indexes.
Response carrying the component-selected statistics snapshot of one catalog.
Statistics of the requested catalog. Present even when the catalog is corrupted, in which case `identity.unusable` is true and most components report `AVAILABILITY_CATALOG_UNUSABLE` instead of carrying a value.
Procedure used to obtain server configuration.
Response to an evitaDB configuration request. This RPC (and therefore this response) is unavailable while the engine runs in read-only mode - see GrpcEvitaEngineSettingsResponse for the smaller, always-available subset of configuration.
Current configuration of the server in YAML format with evaluated values.
Procedure used to obtain the curated subset of the engine configuration that is safe to expose to any client. Unlike GetConfiguration this procedure is available also when the engine runs in read-only mode.
Response to an evitaDB engine settings request. Carries the curated subset of the engine configuration that clients need in order to reason about the behaviour of the server they talk to. Unlike GrpcEvitaConfigurationResponse - which renders the entire configuration file including paths and credentials, and is refused while the engine runs in read-only mode - the values collected here carry nothing sensitive and remain readable in read-only mode. The message is intentionally flat rather than mirroring the sectioning of the configuration file: only a small fraction of the configuration is client-actionable, 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. All values originate from the configuration file and are therefore constant for the entire lifetime of the server process - a client may safely cache the response until it reconnects. Live state that changes while the server runs (readiness, health problems, catalog counts) and the enabled external APIs with their URLs are deliberately absent - they belong to GrpcEvitaServerStatusResponse, which must not be cached.
The engine-wide default conflict resolution applied to a transaction commit when neither the catalog schema nor the entity schema declares its own - the base of the conflict resolution precedence walk.
True when the engine retains historical data, so queries and restores targeting a past point in time are available at all.
True when clients may subscribe to change data capture streams.
True when the server records client traffic, so recordings can be started, inspected and exported.
True when the engine caches computed query results; affects latency characteristics only, never query results.
Procedure used to obtain a component-selected statistics snapshot of one entity collection. This is the only way to obtain per-collection numbers - the catalog-level procedures report aggregates and never break them down by collection.
Request for a component-selected statistics snapshot of one entity collection of one catalog.
Name of the catalog holding the collection. A catalog the server does not know is an error.
Name of the entity collection to describe, i.e. its entity type. A collection the catalog does not hold is an error, not an empty response - an empty response would be indistinguishable from an empty collection.
The components to compute. Every one of them must have a collection-level form - naming a catalog-only component (`COMPONENT_SESSIONS`, `COMPONENT_COMMIT_PIPELINE`, `COMPONENT_ACTIVITY`, `COMPONENT_HISTORY`, `COMPONENT_DURABILITY`) is rejected, as is `COMPONENT_UNSPECIFIED` and an empty list. `COMPONENT_IDENTITY` is delivered whether or not it appears here.
Response carrying the component-selected statistics snapshot of one entity collection.
Statistics of the requested entity collection.
Procedure used to get single file by its id available for fetching.
Request to get a single file available for fetching, by its id.
Identification of the file
Response to a request for a single file available for fetching. If no file exists for the given id, the call fails with an error instead of returning this message.
Descriptor of the requested file.
Procedure used to describe one index in full - what it occupies on the heap, and how well it discriminates. The drill-down that follows `BrowseIndexes`. The caller names the index, and that is what bounds the cost: the heap estimate walks the index's contents, so this is affordable for one index and would not be for a collection holding hundreds of thousands. There is deliberately no procedure that measures a whole collection; a client that wants a total calls this in parallel and sums the results.
Request describing one index in full. The drill-down that follows `BrowseIndexes`: hand back the `entityType` and `indexPrimaryKey` of the row that looked worth investigating - the two together are the index's identity, since the same handle under another owner is another index. The caller naming one index is what bounds the cost of the heap estimate, so there is deliberately no variant of this request that describes several indexes or a whole collection - a client that wants a total issues these calls in parallel and sums the results itself.
Name of the catalog holding the index. A catalog the server does not know is an error.
Name of the entity collection holding the index, i.e. its entity type. A collection the catalog does not hold is an error. Unset describes an index the catalog holds itself.
Identity of the index to describe, as reported by `GrpcBrowsedIndex.indexPrimaryKey`. An index the named owner no longer holds is an error rather than an empty response, which would be indistinguishable from an index that weighs nothing. It is an ordinary outcome rather than necessarily a mistake - a collection's index can be reclaimed between the browse and the drill-down, and a catalog's is created lazily per scope - but it can never mean the handle now denotes a different index.
Response carrying the full description of one index.
The described index.
Procedure used to get detail of particular task status.
Request to get single task status by id
Identification of the task
Response to a task status request.
Status of the requested task. If no task exists for the given id, the server currently does not send this response message at all, rather than sending it with this field unset - for this unary call, that means the call does not complete normally rather than yielding an empty result (the bundled Java driver, for one, surfaces this as a `StatusRuntimeException` with status `INTERNAL`). Prefer `GetTaskStatuses` (plural) if an unknown id must not surface as an error, since it returns a normal (possibly empty) response instead.
Procedure used to get multiple details of particular task statuses.
Request to get multiple task statuses.
Identifications of the tasks whose statuses should be returned. Ids that don't match any known task are silently omitted from the response - see `GrpcSpecifiedTaskStatusesResponse.taskStatus`.
Response to a multiple task statuses request.
Statuses of the requested tasks that were found, in no particular order; ids from the request that don't match any known task are simply absent here, no error is raised for them.
Procedure used to get listing of files available for fetching.
Request to list files available for fetching, in paginated form.
Page number of the files to be listed. Page-based paging: 1-indexed, page 1 is the first page (see `io.evitadb.dataType.PaginatedList#getPageNumber`).
Number of files per page. No server-side maximum is enforced.
File origins to filter by (see `GrpcFile.origin` - usually the `taskType` of the task that produced the file, e.g. `BackupTask`); a file matches if its origin is any of the listed values. Empty (the default) means no filtering - files of all origins are returned.
Response to a request to list files available for fetching.
The page size that was actually applied (echoes the request's `pageSize`).
The page number that was actually applied (echoes the request's `pageNumber`); 1-indexed, see `GrpcFilesToFetchRequest.pageNumber` for the paging model.
Files on this page, matching the origin filter from the request.
Total number of files matching the request's origin filter across all pages, not just this one.
List reserved keywords
Response that returns information about reserved keywords.
All reserved keywords, across all classifier types.
Procedure used to report how often each schema capability of one owner was asked for by queries, against how often mutations had to maintain it - the "you never filter by EAN, so why are you paying to keep its filter index up to date?" reading. Which owner is reported is chosen by `GrpcSchemaCapabilityUsageRequest.entityType`. Where `BrowseIndexes` enumerates the physical indexes and what each of them costs, this reports the schema flags those indexes exist to serve. That is the granularity an operator can act on, since dropping a flag is one schema mutation that removes every index maintaining it at once - and it is why the two are separate procedures rather than extra fields on a browse row. Read `GrpcSchemaCapabilityUsage` before acting on either count; in particular the request count is not physical index usage. Unlike the collection form of `BrowseIndexes` this one is cheap and may be polled: the response is bounded by the schema rather than by the data, and there is no index walk behind it.
Request listing how often each schema capability of one owner was asked for by queries, against how often mutations had to maintain it. `entityType` chooses the owner and is the only thing that does, exactly as it is for an index browse - which is why this request carries no paging, no filters and no ordering: the response is bounded by the schema, dozens of rows per owner, rather than by the data.
Name of the catalog holding the schema. A catalog the server does not know is an error.
Name of the entity collection whose capabilities to report, i.e. its entity type. A collection the catalog does not hold is an error, not an empty list - an empty list would be indistinguishable from a collection nothing has queried. Unset reports the capabilities the catalog schema declares itself - those of its globally-unique attributes, which live there because a query filtering by one may name no collection at all. Both forms answer with the same rows, and every row names its owner, so a client wanting the whole picture issues one call per owner and concatenates the results.
Response carrying every schema capability one owner has observed so far.
The rows, ordered by container, then element name, then element kind, then capability, then scope - a stable order so that two polls of an unchanged catalog do not reshuffle a table an operator is reading, and so that the rows of one element arrive together. Empty when nothing has been observed since the server loaded the catalog.
Procedure used to get listing of task statuses.
Request to list task statuses in paginated form.
Page number of the task statuses to be listed. Page-based paging: 1-indexed, page 1 is the first page (see `io.evitadb.dataType.PaginatedList#getPageNumber`).
Number of task statuses per page. No server-side maximum is enforced.
Task type names to filter by (matched against `GrpcTaskStatus.taskType`); a task matches if its type is any of the listed values. Empty (the default) means no filtering by type.
Simplified task states to filter by; a task matches if its state is any of the listed values. Empty (the default) means no filtering by state. When both `taskType` and `simplifiedState` are non-empty, a task must satisfy both filters.
Response to a task statuses request.
The page size that was actually applied (echoes the request's `pageSize`).
The page number that was actually applied (echoes the request's `pageNumber`); 1-indexed, see `GrpcTaskStatusesRequest.pageNumber` for the paging model.
Task statuses on this page, matching the filters from the request.
Total number of task statuses matching the request's filters across all pages, not just this one.
Procedure used to restore a catalog from a client-uploaded backup via true gRPC client streaming; see `RestoreCatalogUnary` for the chunked-unary alternative.
One chunk of a streamed catalog restore. The client sends a sequence of these messages over the same gRPC client stream, each carrying one slice of the backup archive; the server concatenates `backupFile` across all messages, in arrival order, into a single ZIP file. `catalogName` is expected to be identical on every chunk - only the value from the last message in the stream is actually used to name the restored catalog.
Name of the target catalog into which the backup will be restored. Must not clash with the name of any existing catalog.
One chunk of the binary backup ZIP archive; concatenate `backupFile` from all messages in the stream, in order, to reconstruct the full archive.
Procedure used to restore a catalog from a backup file already stored on the server, without re-uploading it.
Request to restore a catalog from a backup file that already exists on the server (e.g. produced by a prior backup task, or a previous restore upload) - in contrast to `GrpcRestoreCatalogRequest` and `GrpcRestoreCatalogUnaryRequest`, which upload a new backup file as part of the call.
Name of the target catalog into which the backup will be restored. Must not clash with the name of any existing catalog.
Identification of the backup file already stored on the server that should be restored.
Procedure used to put a catalog back to an earlier version of itself, replacing the catalog currently served under the target name. Nothing is uploaded - the server backs up the requested version and restores it in one tracked operation. BEWARE: this purges the replaced catalog.
Request to put a catalog back to the state it was in at an earlier version, replacing the catalog currently served under `targetCatalogName` with it. Unlike `GrpcRestoreCatalogRequest` and friends, nothing is uploaded: the server takes the backup of the requested version itself, unpacks it into a temporary catalog, loads it, and swaps it in - all as the one task returned in the response. BEWARE: this destroys data. The catalog replaced under `targetCatalogName` is purged with every version of it; the restored catalog carries no mutation history, so it cannot itself be restored to an earlier version afterwards; and writes committed to the replaced catalog after the selected version - including ones committed while the operation runs - go with it.
Name of the catalog whose past state is to be restored.
The moment in time to restore the catalog to. If unset, defaults to the current state (subject to being overridden by `catalogVersion`, see below).
Precise catalog version to restore to - this is the version reported by the mutation history. If unset, defaults to the version resolved from `pastMoment`, or to the current state when that is unset too. When this field is set, `pastMoment` is ignored regardless of whether it is also set.
Name of the catalog the restored state is to be served under. If unset - or equal to `catalogName` - the catalog the state was taken from is the one replaced. A different name is accepted whether or not a catalog already holds it: an existing one is replaced on the same terms, a free one is created.
Response to a request to restore a catalog to an earlier version.
The task tracking the whole backup-restore-swap operation; poll its status (`GetTaskStatus`) to observe progress. It completes once the restored catalog is the one being served.
Procedure used to restore a catalog from a client-uploaded backup, one chunk per call (unary version for gRPC/web, where true client streaming as in `RestoreCatalog` is unavailable).
One chunk of a catalog restore uploaded via repeated unary calls, used where true client-side streaming (as in `GrpcRestoreCatalogRequest`) is unavailable, e.g. gRPC-Web. The client calls `RestoreCatalogUnary` once per chunk, feeding back the `fileId` it received in the previous response so the server appends to the same upload; see `GrpcRestoreCatalogUnaryResponse`.
Name of the target catalog into which the backup will be restored. Must not clash with the name of any existing catalog.
One chunk of the binary backup ZIP archive; the server appends it to the chunks already received for this upload (identified by `fileId`).
Identifies the upload this chunk continues. If unset, this is the first chunk of a new upload: the server allocates a new upload id and returns it as `fileId` in the response. If set, it must be a `fileId` previously returned for this same upload, and this chunk is appended to it.
Total size of the complete backup file (bytes), as expected once all chunks have been received; sent with every chunk. Once the bytes received so far reach exactly this size, the restore starts automatically. If more bytes are received than this, the server still returns a normal response for that (final) chunk and only afterwards discards the partial upload - an overshoot is not guaranteed to surface to the client as an error, so do not exceed it.
Response to a catalog restore request (unary variant). This is used for gRPC/web. We need to explicitly handle the fileId, because it gets repeatedly updated (appended) from the client.
Cumulative number of bytes received for this upload so far, across this and all preceding chunks (bytes).
Identifies this upload. Echo this value back as `fileId` in the next `GrpcRestoreCatalogUnaryRequest` chunk so the server appends to the same upload; on the first chunk of an upload the server allocates this id and returns it here for the first time.
The task tracking the restore operation; poll its status (`GetTaskStatus`) to observe restore progress.
Procedure used to obtain server status.
Response to a server status request.
Version of evitaDB server taken from the MANIFEST.MF file
Date and time when the server was started
Duration of time since the server was started (seconds)
Unique identifier of the server instance
Number of corrupted catalogs
Deprecated since 2025.7 - number of catalogs that are active and has been successfully loaded, renamed to `catalogsActive`
Health problems currently detected by any of the server's health probes, deduplicated. Empty means no problems were detected.
Overall readiness of the evitaDB server
Status keyed by API code, for every external API registered on the classpath - including ones that are disabled (`GrpcApiStatus.enabled == false`) or have no registered provider (in which case `baseUrl` and `endpoints` are empty). Presence in this map does not imply the API is enabled or reachable; check `GrpcApiStatus.enabled`/`ready`.
Flag indicating that the server is in read-only mode
Number of catalogs that are active and has been successfully loaded
Number of inactive catalogs
Monotonically increasing version number of the engine's own state, distinct from any single catalog's version - incremented once for each committed engine-level change (e.g. a catalog being created, removed, renamed, or having its format upgraded or read-only mode toggled). Ordinary data mutations within a catalog do not advance it.
The date and time when the current engine version was introduced (last engine level change occurred).
This service contains RPCs that could be called by gRPC clients on evitaDB. Main purpose of this service is to provide a way to create sessions and catalogs, and to update the catalog.
Procedure used to activate a catalog.
Response to an activate catalog request.
Indicator whether the catalog was activated successfully.
Procedure used to activate a catalog with progress tracking.
Procedure used to update the catalog with a set of mutations.
Response to apply mutation on engine level.
(message has no fields)
Procedure used to update the catalog with a set of mutations which tracks the progress of the operation.
Procedure used to create read-only session which will return data in binary format. Part of the Private API.
Procedure used to create read-write session which will return data in binary format. Part of the Private API.
Procedure used to create read only sessions.
Procedure used to create read write sessions.
Procedure used to deactivate a catalog.
Response to a deactivate catalog request.
Indicator whether the catalog was deactivated successfully.
Procedure used to deactivate a catalog with progress tracking.
Procedure used to define a new catalog.
Request to define a new catalog.
Name of the catalog to be defined.
Response to a catalog definition request.
Indicator whether the catalog was defined successfully.
Procedure used to delete an existing catalog.
Request to delete a catalog.
Name of the catalog to be deleted.
Response to a catalog deletion request.
Indicator whether the catalog was deleted successfully.
Procedure used to duplicate a catalog.
Response to a duplicate catalog request.
Indicator whether the catalog was duplicated successfully.
Procedure used to duplicate a catalog with progress tracking.
Procedure used to get names of all existing catalogs.
Response to a catalog names request.
Names of all existing catalogs.
Procedure used to get state of the catalog by its name.
Request to a get catalog state request.
Name of the catalog to be checked for state.
Response to a get catalog state request.
State of the catalog. Unset if no catalog with the requested name exists.
Procedure used to initiate progress consumption for top-level engine mutations.
Request to get progress of the top-level engine mutations.
The name of the catalog for which the progress is requested. Might be empty if the progress is not related to any catalog and is related to the whole evitaDB instance.
Response to GrpcGetProgressRequest.
True when a mutation progress was being tracked for `catalogName` at the moment this call was received. If `false`, none of the fields below carry information - either no mutation is currently in flight for this catalog, or a previously tracked one already finished (and its progress entry was cleared) before this call arrived; the call must be made while the operation is still running in order to observe it.
Current progress of the tracked mutation (percent, 0-100). Unset iff `found` is `false`. The final streamed message carries 100; intermediate updates are throttled (only sent on an increase, at most once per second).
Catalog name copied from the request. Empty when `found` is `false`.
Catalog version reached by the operation. Set only on the final streamed message (`progressInPercent` = 100), and only if the operation produced a catalog version (i.e. relates to a catalog rather than being purely engine-level); unset on every intermediate update.
Catalog schema version reached by the operation. Set only on the final streamed message (`progressInPercent` = 100), and only if the operation produced a catalog schema version (i.e. relates to a catalog rather than being purely engine-level); unset on every intermediate update.
Procedure used to check readiness of the API
Response to a server status request.
Always true when returned
Procedure used to make a catalog alive.
Response to a make catalog alive request.
Indicator whether the catalog was made alive successfully.
Procedure used to make a catalog alive with progress tracking.
Procedure used to make a catalog immutable.
Response to a make catalog immutable request.
Indicator whether the catalog was made immutable successfully.
Procedure used to make a catalog immutable with progress tracking.
Procedure used to make a catalog mutable.
Response to a make catalog mutable request.
Indicator whether the catalog was made mutable successfully.
Procedure used to make a catalog mutable with progress tracking.
Procedure used to register a system change capture.
Request to register a system change capture.
Starting point for the search (engine version). If `null`, the capture starts live-tailing from the most recent / greatest available engine version rather than replaying history from the beginning.
Continuation point within `sinceVersion` (index of the mutation within the engine version - currently each engine level transaction contains only one mutation). If `null`, the capture starts at the beginning of `sinceVersion` rather than resuming mid-transaction.
Requested content of the capture - i.e. whether client wants to receive only the simple notification about the change or whether he wants to receive the full content of the change
OR-ed criteria for the capture. When empty, defaults to ENGINE only on the system stream (NOTE: this differs from the catalog stream, which defaults to all areas including INFRASTRUCTURE). HOST on the system stream requires explicit opt-in.
Response to GrpcRegisterSystemChangeCapture request.
Identification of the registered subscription. Set on `ACKNOWLEDGEMENT` and `HEARTBEAT` responses (when a subscription id is available), unset on `CHANGE` responses.
A single captured CDC event that matched the subscription's criteria - each stream message carries at most one event, not a batch. Set only when `responseType` is `CHANGE`; unset on `ACKNOWLEDGEMENT` and `HEARTBEAT` responses.
The kind of this response: `ACKNOWLEDGEMENT` is sent exactly once, when the subscription is set up; `CHANGE` is sent for each matching capture event; `HEARTBEAT` is sent periodically as a keep-alive while no matching event has occurred.
Heartbeat information. Set only on `ACKNOWLEDGEMENT` and `HEARTBEAT` responses, unset on `CHANGE` responses.
Procedure used to rename an existing catalog.
Response to a catalog rename request.
Indicator whether the catalog was renamed successfully.
Procedure used to rename an existing catalog with progress tracking.
Procedure used to replace an existing catalog.
Response to a catalog replace request.
Indicator whether the catalog was replaced successfully.
Procedure used to replace an existing catalog with progress tracking.
Procedure used to terminate existing session.
Request to terminate a session.
UUID of the session to be terminated.
Response to a session termination request.
Indicator whether the session was terminated successfully.
This service contains RPCs that could be called by gRPC clients on evitaDB's catalog by usage of a before created session. By specifying its UUID and the name of a catalog to which it corresponds to it's possible to execute methods that in evitaDB's implementation a called on an instance of EvitaSessionContract. Main purpose of this service is to provide a way to manipulate with stored entity collections and their schemas. That includes their creating, updating and deleting. Same operations could be done with entities, which in addition could be fetched by specifying a complex queries.
Applies single mutation to the entity.
Procedure that archives an entity and returns it with required richness.
Request for archiving a single entity by primary key and returning it fetched in the richness described by `require`.
Entity type (collection name) the entity to archive belongs to.
Primary key of the entity to archive. Effectively mandatory despite the wrapper type: the server reads its value directly without checking presence, so an unset value is treated identically to an explicit `0` rather than as "no primary key" - always set this field explicitly.
The string part of a parametrised `require` query fragment describing how richly to fetch the entity back after it is archived. `?`/`@name` placeholders are bound the same way as `positionalQueryParams`/`namedQueryParams` on `GrpcEntityRequest` - see there for the full binding contract.
Values for the `?` positional placeholders in `require`, bound in encounter order (FIFO) - see `GrpcEntityRequest.positionalQueryParams` for the full binding contract.
Values for the `@name` named placeholders in `require`, keyed by name (without the `@` prefix) - see `GrpcEntityRequest.namedQueryParams` for the full binding contract.
Response to ArchiveEntity request.
At most one of these is set. If an entity with the requested primary key existed and was archived, which field is chosen by whether `GrpcArchiveEntityRequest.require` has an `entityFetch` requirement: `entity` (fully fetched) if it does, `entityReference` otherwise. Neither is set if no entity with the requested primary key existed to archive.
The archived entity as a reference (type + primary key only).
The archived entity, fully fetched per `GrpcArchiveEntityRequest.require`.
Procedure used to backup an existing catalog.
Procedure used to backup an existing catalog, streaming progress updates.
Procedure that closes the session.
Request for Close, which commits or rollbacks the changes in the session and terminates it.
Contains the requested commit behaviour
Name of the catalog to which the session relates.
When true, the session's transaction is discarded (rolled back) instead of committed. The client sets this when an exception escaped the transaction block uncaught, so the server rolls back exactly as an embedded session would. When false (the default) the surviving changes are committed.
Response for Close request that commits or rollbacks the changes in the session.
Contains next catalog version
Contains the version of the catalog schema that will be valid at the moment of closing the session. If session relates to a writable transaction, this schema version becomes valid at the moment the next catalog version (i.e. the one that is returned in the response) becomes visible.
Procedure that closes the session opening a stream that listens to transaction processing phases.
Request for CloseGrpcCloseWithProgress procedure that commits or rollbacks the changes in the session.
Name of the catalog to which the session relates.
When true, the session's transaction is discarded (rolled back) instead of committed. The client sets this when an exception escaped the transaction block uncaught, so the server rolls back exactly as an embedded session would. When false (the default) the surviving changes are committed.
Response for CloseGrpcCloseWithProgress request that commits or rollbacks the changes in the session.
Contains next catalog version
Contains the version of the catalog schema that will be valid at the moment of closing the session. If session relates to a writable transaction, this schema version becomes valid at the moment the next catalog version (i.e. the one that is returned in the response) becomes visible.
The successfully finished phase of the transaction.
Procedure that defines the schema of a new entity type and return it.
Request for defining the schema of a new entity type.
The schema of the new entity type.
Response to DefineEntitySchema request.
Newly created entity schema.
Procedure that deletes an entity collection.
Request for deleting an entity collection.
The entity type of the collection to be deleted.
Response to DeleteCollection request.
True, if the collection was deleted.
Procedure that deletes all entities that match the sent query and returns their bodies.
Request for deleting all entities matched by a query. Beware: without a `page()`/`strip()` requirement in the query's `require` block to bound the result, at most 20 entities are deleted (the engine's default page size) - add an explicit `page()`/`strip()` requirement to remove more.
The string part of the parametrised query. `?`/`@name` placeholders are bound the same way as `positionalQueryParams`/`namedQueryParams` on `GrpcEntityRequest` - see there for the full binding contract.
Values for the `?` positional placeholders in `query`, bound in encounter order (FIFO) - see `GrpcEntityRequest.positionalQueryParams` for the full binding contract.
Values for the `@name` named placeholders in `query`, keyed by name (without the `@` prefix) - see `GrpcEntityRequest.namedQueryParams` for the full binding contract.
Response to DeleteEntities request that deletes all entities matched by the sent query.
Total number of entities deleted.
The deleted entities' bodies, fully fetched (as they were immediately before deletion) per the `require` block of the query in `GrpcDeleteEntitiesRequest`. Empty if that `require` block had no `entityFetch` requirement.
Procedure that deletes an entity and returns it with required richness.
Response to DeleteEntity request.
At most one of these is set. If an entity with the requested primary key existed and was deleted, which field is chosen by whether `GrpcDeleteEntityRequest.require` has an `entityFetch` requirement: `entity` (fully fetched, as it was immediately before deletion) if it does, `entityReference` otherwise. Neither is set if no entity with the requested primary key existed to delete.
The deleted entity as a reference (type + primary key only).
The deleted entity, fully fetched (as it was immediately before deletion) per `GrpcDeleteEntityRequest.require`.
Procedure that deletes an entity and its hierarchy and returns the root entity with required richness.
Response to DeleteEntityAndItsHierarchy, which removes a hierarchical root entity together with every entity of the same type that transitively references it as a parent.
Total number of entities deleted (the root plus its whole nested hierarchy).
At most one of these is set. Unlike the equivalent oneof on `GrpcDeleteEntityResponse`, this RPC always fetches the root entity's body - even when `GrpcDeleteEntityRequest.require` is empty - so in practice `deletedRootEntity` is the field that gets populated; `deletedRootEntityReference` is currently unreachable in the server implementation. Neither is set if no entity with the requested primary key existed to delete. Covers only the root entity - the rest of the deleted hierarchy is available solely as primary keys via `deletedEntityPrimaryKeys` below.
The deleted root entity as a reference (type + primary key only). Currently never populated by the server - see the message-level comment above.
The deleted root entity, fully fetched (as it was immediately before deletion) per `GrpcDeleteEntityRequest.require`.
Primary keys of every entity deleted as part of the hierarchy removal, including the root entity's own primary key.
Procedure used to backup an existing catalog.
Procedure used to fully backup an existing catalog, streaming progress updates.
Procedure that returns the list of all entity types.
Response to GetAllEntityTypes request.
Names of all entity collections (entity types) defined in the catalog.
Procedure that returns the current (the one on which the used session operates) catalog schema.
Request to GetCatalogSchema request.
True, if the schema should include name variants for it and all sub-schemas. This could considerably increase the size of the response.
Response to GetCatalogSchema request.
The current catalog schema.
The current catalog version (data version, incremented with each transaction commit). Zero for catalogs that are in the warming-up state.
The current catalog schema version.
Procedure that returns the current state of the catalog.
Response to GetCatalogState request.
The current state of the catalog.
Procedure that returns the version of the catalog at a specific moment in time.
Request to GrpcCatalogVersionAt request.
Chosen moment in time for which the version of the catalog should be returned.
Signalizes whether the returned version should be the closest one before the specified moment or the closest one after the specified moment
Response to GrpcCatalogVersionAt request.
The first version of the materialized version block visible in the specified time
The last version of the materialized version block visible in the specified time
Exact moment when this materialized version block was introduced to the catalog snapshot
Procedure that find entity by passed entity type and primary key and return it by specified richness by passed parametrised require query part.
Request for acquiring a single entity by primary key, in the richness described by `require`.
The primary key of the entity to fetch.
The entity type (collection name) the primary key belongs to.
The string part of a parametrised `require` query fragment (e.g. `entityFetch(attributeContentAll())`), parsed on the server. Parameter values are not embedded in this string but supplied separately via `positionalQueryParams`/`namedQueryParams` below. A `?` placeholder in this string is a positional parameter, an `@name` placeholder is a named parameter - see `positionalQueryParams`/`namedQueryParams` below for the full binding contract, which applies identically here.
Values for the `?` positional placeholders in `require`, bound in encounter order: the first `?` in the parsed string binds to `positionalQueryParams[0]`, the second to `positionalQueryParams[1]`, and so on (FIFO). Supplying fewer values than there are `?` placeholders fails the request with "Missing argument of index N."; extra values are ignored.
Values for the `@name` named placeholders in `require`, keyed by the name used after `@` in the string (without the `@` prefix). An `@name` placeholder with no matching map entry fails the request with "Missing argument of name `name`."; extra map entries are ignored.
Scopes to search for the entity in. An empty list defaults to searching only the `LIVE` scope - `ARCHIVED` entities are not matched unless `ARCHIVED_ENTITY` is explicitly included here.
Response to GetEntity request.
The found entity. Unset (not an error) if no entity with the requested primary key exists in `entityType` within the requested `scopes`.
Procedure that returns the size of an entity collection.
Request for acquiring the size of an entity collection.
The entity type (collection name) whose size (count of entities stored) should be returned.
Response to GetEntityCollectionSize request.
The size of the collection.
Procedure that returns the schema of a specific entity type.
Request for acquiring the schema of a specific entity type.
The entity type for which the schema is requested.
True, if the schema should include name variants for it and all sub-schemas. This could considerably increase the size of the response.
Response to GetEntitySchema request.
The schema of the requested entity type.
Procedure that returns stream of all past mutations in reversed (newest-first) order that match the request criteria.
Procedure that returns stream of all past mutations in chronological (oldest-first) order that match the request criteria - the forward counterpart of GetMutationsHistory.
Procedure that returns requested page of past mutations in reversed (newest-first) order that match the request criteria.
Procedure that returns requested page of past mutations in chronological (oldest-first) order that match the request criteria - the forward counterpart of GetMutationsHistoryPage.
Procedure that opens a transaction.
Response to GetTransactionId request, returned after a new transaction is opened.
The current version of the catalog the transaction is bound to.
The id of the opened transaction.
Procedure that returns details of a specific transactions that move catalog to specified versions.
Request to GetTransactionOverview request.
The catalog versions to return the transaction overview for. See `GetTransactionOverviewResponse` for the ordering and completeness contract of the response.
Response to GetTransactionOverview request. Entries preserve the relative order of the requested `catalogVersion` list, but a version unknown to history - purged, or never committed - is omitted rather than padded with an empty entry. The response can therefore be shorter than the request, and can be empty; it is not an error to ask for a version history no longer holds.
The transaction overviews for those requested catalog versions that are still known to history, in request order. Because unknown versions are omitted rather than padded, positions do not line up with the request - correlate each entry by its own `catalogVersion` field, never by index.
Procedure that changes the state of the catalog to ALIVE and closes the session.
Response for GoLiveAndClose request that switches the catalog to ALIVE state and closes the session.
True, if the catalog was switched to ALIVE state.
Contains next catalog version
Contains the version of the catalog schema that will be valid at the moment of closing the session. If session relates to a writable transaction, this schema version becomes valid at the moment the next catalog version (i.e. the one that is returned in the response) becomes visible.
Procedure that changes the state of the catalog to ALIVE and closes the session opening a stream that listens to updates of go live procedure.
One message of the GoLiveAndCloseWithProgress stream. Intermediate messages report only `progressInPercent` (throttled to at most once per second, and only when the percentage has increased); `catalogVersion`/`catalogSchemaVersion` are left at their zero default on those messages since they are not yet meaningful. The final message always carries `progressInPercent == 100` together with a populated `catalogVersion`/`catalogSchemaVersion`, and ends the stream.
Contains next catalog version. Only populated on the final message (`progressInPercent == 100`); left at its default (`0`) on intermediate progress-only messages.
Contains the version of the catalog schema that will be valid at the moment of closing the session. If session relates to a writable transaction, this schema version becomes valid at the moment the next catalog version (i.e. the one that is returned in the response) becomes visible. Only populated on the final message (`progressInPercent == 100`); left at its default (`0`) on intermediate progress-only messages.
Progress of the go-live operation, 0-100. Monotonically increasing across messages; the final message in the stream always carries 100.
Procedure that executes passed parametrised query and returns a data chunk with computed extra results.
Procedure that executes passed parametrised query and returns a list of entities.
Procedure that executes passed query with embedded variables and returns a list of entities. Do not use in your applications! This method is unsafe and should be used only for internal purposes.
Procedure that executes passed parametrised query and returns zero or one entity.
Procedure that executes passed query with embedded variables and returns zero or one entity. Do not use in your applications! This method is unsafe and should be used only for internal purposes.
Procedure that executes passed query with embedded variables and returns a data chunk with computed extra results. Do not use in your applications! This method is unsafe and should be used only for internal purposes.
Procedure that registers a change capture.
Request to open a live subscription (RegisterChangeCatalogCapture) that streams mutations as they commit, optionally preceded by a historical replay starting at `sinceVersion`/`sinceIndex`.
Catalog version from which to start the historical replay portion of the subscription (inclusive). If unset, defaults to the current catalog version plus one, i.e. only mutations committed after the subscription is registered are delivered, with no historical replay.
Index of the mutation within `sinceVersion` from which to start the historical replay (inclusive). A version's mutations are numbered from 1 upward; the transaction header itself occupies index 0. If unset, defaults to 0, i.e. starting from that version's transaction header.
Criteria mutations must match to be included (entity type, mutation kind, area, etc.). An empty list applies no criteria-based filtering.
Whether delivered captures carry only mutation headers (`CHANGE_HEADER`, the default - proto3 zero value - when this field is left unset) or full mutation bodies (`CHANGE_BODY`).
One message of the RegisterChangeCatalogCapture stream. `responseType` selects which payload is meaningful: `ACKNOWLEDGEMENT` (subscription set up; `heartBeat` populated, `capture` is not), `CHANGE` (`capture` populated, `heartBeat` is not), or `HEARTBEAT` (`heartBeat` populated, `capture` is not) - the periodic keep-alive sent while no matching mutation has occurred.
Identification of the registered subscription. Present on every message, not just the initial acknowledgement.
The single mutation (CDC event) delivered by this message. Populated only when `responseType` is `CHANGE`; unset otherwise.
Which payload field (`capture` or `heartBeat`) is populated on this message - see the message-level comment above.
Heartbeat information. Populated when `responseType` is `ACKNOWLEDGEMENT` or `HEARTBEAT`; unset when `responseType` is `CHANGE`.
Procedure that renames an entity collection.
Request for renaming an entity collection.
The entity type of the collection to be renamed.
The new name of the collection.
Response to RenameCollection request.
True, if the collection was renamed.
Procedure that replaces an entity collection.
Request for replacing an entity collection's contents with those of another collection. On success, `entityTypeToBeReplaced` is purged and its name is taken over by the (dropped) `entityTypeToBeReplacedWith` collection. If an error occurs mid-operation, both collections are guaranteed to be left untouched under their original names.
Name of the collection that will be replaced: its current contents are dropped, and it will end up holding the contents of `entityTypeToBeReplacedWith` under this same name.
Name of the collection whose contents become the new contents of `entityTypeToBeReplaced`. This collection itself no longer exists under its own name once the replacement completes.
Response to ReplaceCollection request.
True, if the collection was replaced.
Procedure that restores an entity and returns it with required richness.
Request for restoring a single previously archived entity by primary key and returning it fetched in the richness described by `require`.
Entity type (collection name) the entity to restore belongs to.
Primary key of the entity to restore. Effectively mandatory despite the wrapper type: the server reads its value directly without checking presence, so an unset value is treated identically to an explicit `0` rather than as "no primary key" - always set this field explicitly.
The string part of a parametrised `require` query fragment describing how richly to fetch the entity back after it is restored. `?`/`@name` placeholders are bound the same way as `positionalQueryParams`/`namedQueryParams` on `GrpcEntityRequest` - see there for the full binding contract.
Values for the `?` positional placeholders in `require`, bound in encounter order (FIFO) - see `GrpcEntityRequest.positionalQueryParams` for the full binding contract.
Values for the `@name` named placeholders in `require`, keyed by name (without the `@` prefix) - see `GrpcEntityRequest.namedQueryParams` for the full binding contract.
Response to RestoreEntity request.
At most one of these is set. If an entity with the requested primary key existed and was restored, which field is chosen by whether `GrpcRestoreEntityRequest.require` has an `entityFetch` requirement: `entity` (fully fetched) if it does, `entityReference` otherwise. Neither is set if no archived entity with the requested primary key existed to restore.
The restored entity as a reference (type + primary key only).
The restored entity, fully fetched per `GrpcRestoreEntityRequest.require`.
Procedure that updates the catalog schema and returns it.
Response to UpdateAndFetchCatalogSchema request, which updates the catalog schema and returns the resulting schema in one round trip.
The catalog schema after the requested mutations were applied.
Procedure that updates the schema of an existing entity type and returns it.
Response to UpdateAndFetchEntitySchema request, which updates an entity type's schema and returns the resulting schema in one round trip.
The entity schema after the requested mutations were applied.
Procedure that updates the catalog schema and return its updated version.
Response to UpdateCatalogSchema request.
The new version of the catalog schema.
Procedure that updates the schema of an existing entity type and return its updated version.
Response to UpdateEntitySchema request.
The new version of the entity schema.
Procedure that upserts (inserts/updates) an entity and returns it with required richness.
Request for upserting (inserting/updating) an entity and returning it fetched in the richness described by `require`.
The mutation to apply - either an upsert (insert/update) or a delete mutation for the entity.
The string part of a parametrised `require` query fragment (e.g. `entityFetch(attributeContentAll())`) describing how richly to fetch the entity back after the mutation is applied. `?`/`@name` placeholders are bound the same way as `positionalQueryParams`/`namedQueryParams` on `GrpcEntityRequest` - see there for the full binding contract.
Values for the `?` positional placeholders in `require`, bound in encounter order (FIFO) - see `GrpcEntityRequest.positionalQueryParams` for the full binding contract.
Values for the `@name` named placeholders in `require`, keyed by name (without the `@` prefix) - see `GrpcEntityRequest.namedQueryParams` for the full binding contract.
Response to UpsertEntity request.
Exactly one of these is set. `entity` is set when `GrpcUpsertEntityRequest.require` has an `entityFetch` requirement. Otherwise a reference is returned: `entityReferenceWithAssignedPrimaryKeys` when the upsert caused reference primary keys to be reassigned (e.g. due to reflected reference schemas), or plain `entityReference` otherwise.
The upserted entity as a reference (type + primary key only).
The upserted entity, fully fetched per `GrpcUpsertEntityRequest.require`.
The upserted entity reference together with any reference primary keys that were reassigned as a side effect of the upsert.
This service contains RPCs that could be called by gRPC clients on evitaDB's catalog by usage of a before created session. Main purpose of this service is to provide a way to query and manage recorded traffic (queries, mutations, session lifecycle events) captured for diagnostics.
Procedure that exports a consistent, on-demand snapshot of the currently buffered traffic recording window to a downloadable zip archive - not gated by any running recording task.
Request to ExportTrafficRecording request.
The target size of each individual chunk file within the export (bytes); exported files are split into chunks of approximately this size. If unset, or set to zero, the server-configured default chunk size is used.
Procedure that returns stream of all past traffic records that match the request criteria. Order of the returned records is from the newest sessions to the oldest, traffic records within the session are ordered from the newest to the oldest.
Request for the streaming variant of the traffic history query; unlike GetTrafficHistoryListRequest, all matching records are streamed back without a result cap.
The criteria of the traffic recording, allowing constraints on the returned records. If unset, no filters are applied and all recorded traffic is streamed back.
A single streamed response frame carrying traffic records.
The traffic records carried by this streamed frame (the current server implementation emits exactly one record per frame).
Procedure that returns requested list of past traffic records with limited size that match the request criteria. Order of the returned records is from the oldest sessions to the newest, traffic records within the session are ordered from the oldest to the newest.
Procedure that returns requested list of past traffic records with limited size that match the request criteria. Order of the returned records is from the newest sessions to the oldest, traffic records within the session are ordered from the newest to the oldest.
Procedure returns a list of top unique label values ordered by cardinality of their values present in the traffic recording.
Request to GetTrafficRecordingLabelsValuesOrderedByCardinality request.
Maximum number of label values to return, ordered by descending cardinality (most frequently used values first). This is a plain result cap, not page-based or offset-based pagination; repeated calls do not support continuation.
The name of the label to get the values for
Only label values starting with this prefix are returned. If unset, no prefix filter is applied.
Response to GetTrafficRecordingLabelsValuesOrderedByCardinality request.
The label values that match the criteria, ordered by descending cardinality (most frequently used values first).
Procedure returns a list of top unique labels names ordered by cardinality of their values present in the traffic recording.
Request to GetTrafficRecordingLabelsNamesOrderedByCardinality request.
Maximum number of label names to return, ordered by descending cardinality (most frequently used labels first). This is a plain result cap, not page-based or offset-based pagination; repeated calls do not support continuation.
Only label names starting with this prefix are returned. If unset, no prefix filter is applied.
Response to GetTrafficRecordingLabelsNamesOrderedByCardinality request.
The label names that match the criteria, ordered by descending cardinality (most frequently used labels first).
Procedure that starts the traffic recording for the given criteria and settings. Fails if a recording is already in progress - only one recording may run at a time.
Request to start a new traffic recording session. Only one recording may be in progress at a time; starting a new one while another is still running fails.
The sampling rate of the traffic recording (100 means all records will be recorded, 1 means 1% of records will be recorded)
If true the recording will be exported to a file, otherwise only internal ring buffer will be made available for the time the traffic recording is running.
The maximum duration of the recording (milliseconds); the recording stops automatically once this much time has elapsed. If unset, the recording keeps running until explicitly stopped via StopTrafficRecording.
The maximum size of the recorded traffic data (bytes); the recording stops automatically once this much data has been captured. If unset, no size-based automatic stop is applied.
The target size of each individual chunk file within the export (bytes); exported files are split into chunks of approximately this size. If unset, or set to zero, the server-configured default chunk size is used.
Procedure that stops the traffic recording
Request to StopTrafficRecording request.
The ID of the task that started the recording
Structure that holds a map-typed node of a complex associated data value's tree.
Used in:
The child nodes of this map node, keyed by property name.
Request for GetMutationsHistoryPage / GetMutationsHistoryPageForward, a paged read of past mutations (catalog schema changes and entity mutations) that match the given criteria. GetMutationsHistoryPage delivers pages reverse-chronologically (newest first); GetMutationsHistoryPageForward delivers them chronologically (oldest first). The two RPCs share this same request/response message pair; fields whose meaning depends on direction say so explicitly below. A page never splits a single entity/schema mutation from the local-mutation captures it produced. The CDC model has exactly three levels - there is no separate "record" level: the transaction level (`version` alone), the entity/schema-mutation level (`index` within a `version`; index 0 is reserved for the transaction's own lead event), and the local-mutation level (the individual field-level changes an entity mutation fans out into, which share their parent's `(version, index)` instead of getting an index of their own). In this RPC's paging terms, a "record" is simply one `(version, index)` group: either the lone transaction-lead capture by itself, or one entity/schema-mutation capture plus every local-mutation capture it produced. See `GetMutationsHistoryPageResponse` for what that implies for `pageSize` and for completeness checking across page boundaries.
Used as request type in: EvitaSessionService.GetMutationsHistoryPage, EvitaSessionService.GetMutationsHistoryPageForward
The requested page number (1-indexed: page 1 is the first page in whichever direction the RPC traverses - newest-first for GetMutationsHistoryPage, oldest-first for GetMutationsHistoryPageForward). If unset, defaults to 1. Not rejected when it lands past the last available page - the response is simply empty; see `GetMutationsHistoryPageResponse.hasNext` for how to detect the last page.
The number of records to return per page (see the message-level comment for what a record is - this is page-based paging over records, not over individual captures). If unset, defaults to 20. Not rejected or capped when it exceeds the number of available records; the last page is simply shorter. Because pages are record-aligned, the number of `GrpcChangeCatalogCapture` entries actually returned can exceed `pageSize` whenever the last included record fans out into several local-mutation captures - `pageSize` bounds records, not entries.
Catalog version to anchor the search at (inclusive). Meaning depends on which RPC this request is sent to: - GetMutationsHistoryPage (reverse): an upper bound - the anchor to start from and go backward. If unset, defaults to the upper bound implied by the request - the version resolved from `timeFrame`'s upper bound when `timeFrame` is set, otherwise the session's current catalog version. A value above that bound is silently clamped down to it rather than rejected. - GetMutationsHistoryPageForward (forward): a lower bound - the anchor to start from and go forward. If unset, defaults to the lower bound implied by the request - the version resolved from `timeFrame`'s lower bound when set, otherwise the oldest version known to the catalog's mutation history. A value below that bound is silently clamped up to it. A value above the newest available version is not an error - it simply yields an empty result, since "past the newest" is a legitimate (if unusual) floor. Leave this unset only for the very first page of a traversal; from the second page on, pass back `GetMutationsHistoryPageResponse.sinceVersion` from the previous page's response verbatim, to keep the whole traversal anchored to one consistent version - see that field for details.
Index of the mutation within `sinceVersion` to anchor the search at (inclusive). A version's mutations are numbered from 1 upward; the transaction header itself occupies index 0. If unset, defaults to 0 for GetMutationsHistoryPageForward ("start from that version's transaction header") or `Integer.MAX_VALUE` for GetMutationsHistoryPage ("start from the newest mutation of that version"). This default applies independently of whether `sinceVersion` is set - but not independently of whether the resolved `sinceVersion` ends up clamped (up to the forward floor, or down to the reverse ceiling - see `sinceVersion` above): an explicitly set `sinceIndex` is discarded and the direction default used instead whenever that clamp happens, since the client computed it against the original, un-clamped version, and it no longer identifies a valid position in the version actually resolved to.
Restricts the search to mutations committed within this time range. For GetMutationsHistoryPage (reverse), the lower bound (`from`) is exclusive - the version resolved from it is excluded from the result, even though the underlying version-resolution lookup it uses is itself inclusive of that moment. For GetMutationsHistoryPageForward (forward), the upper bound (`to`) is inclusive instead: the last version committed at or before `to` is the traversal's far, stopping edge, and is itself included in the result - not symmetric to `from` on the reverse RPC. A forward `from` moment in the future is not an error either - like an explicit `sinceVersion` past the newest available version (see above), it simply yields an empty result rather than falling back to the newest mutations. Time-to-version resolution for both `from` and `to` is checkpoint-granular, not exact to the mutation's own commit moment - a `from`/`to` that lands inside the current checkpoint interval may include or exclude mutations committed within that same interval on either side of the requested boundary.
Criteria mutations must match to be included (entity type, mutation kind, area, etc.). An empty list applies no criteria-based filtering.
Whether the response carries only mutation headers (`CHANGE_HEADER`, the default - proto3 zero value - when this field is left unset) or full mutation bodies (`CHANGE_BODY`). Only `CHANGE_BODY` carries enough information (e.g. `mutationCount` on the transaction header) to verify a transaction was received in full.
Response to GetMutationsHistoryPage request. Unlike `GrpcPaginatedList`/`GrpcDataChunk` elsewhere in this API, there is no `totalRecordCount` here - a WAL scan cannot produce one cheaply - so `hasNext` is computed by the server peeking one record past the requested page rather than from a precomputed count, and there is no `isLast`/`hasPrevious` counterpart either. See `sinceVersion` below for the anchor-echo mechanism that keeps a multi-page traversal consistent across concurrent commits. Pages never split a `(version, index)` group (see `GetMutationsHistoryPageRequest` for what that means - there is no separate "record level", just the transaction/entity-schema-mutation/local-mutation levels the CDC model actually has). That guarantee holds at the entity/schema-mutation level only, not at the transaction level: a page's first group can be a transaction's non-header entity/schema mutation without that transaction's lead event appearing anywhere in the same page. So the `mutationCount`-based completeness check available on the unpaged `GetMutationsHistory`/`GetMutationsHistoryForward` RPCs is not usable across page boundaries here.
Used as response type in: EvitaSessionService.GetMutationsHistoryPage, EvitaSessionService.GetMutationsHistoryPageForward
The mutations on this page - newest first for GetMutationsHistoryPage, oldest first for GetMutationsHistoryPageForward. Can be shorter than the requested page size - including empty - and, since a page never splits a `(version, index)` group, can also carry more entries than `pageSize` when the last included group fans out into several local-mutation captures; see the message-level comment.
Whether a further page exists beyond this one - see the message-level comment for how this is derived.
The catalog version this page's traversal is anchored to. If the request left `sinceVersion` unset, this reports what the implied bound resolved to: "now" (the newest available version) for GetMutationsHistoryPage, or the oldest known version for GetMutationsHistoryPageForward - no other RPC reports either directly (`GetCatalogVersionAt` with no moment set reports the *oldest* known version only, regardless of direction). Pass this value back as `GetMutationsHistoryPageRequest.sinceVersion` on every subsequent page of the same traversal to keep it anchored to that one version throughout. If `sinceVersion` is instead left unset on every call, each page resolves the bound independently, so a commit landing between page fetches moves it and mutations can be skipped or duplicated across pages.
Request for GetMutationsHistory / GetMutationsHistoryForward, a streamed read of past mutations that match the given criteria - the unpaged sibling of GetMutationsHistoryPage / GetMutationsHistoryPageForward. GetMutationsHistory delivers them reverse-chronologically (newest first); GetMutationsHistoryForward delivers them chronologically (oldest first). The two RPCs share this same request message; `sinceVersion` switches meaning by direction.
Used as request type in: EvitaSessionService.GetMutationsHistory, EvitaSessionService.GetMutationsHistoryForward
Catalog version to anchor the search at (inclusive). For GetMutationsHistory (reverse), an upper bound - the anchor to start from and go backward; if unset, defaults to the engine's last applied catalog version (this default differs from the paged RPC's, which anchors on the session's current catalog version instead - the two can diverge under concurrent writes). For GetMutationsHistoryForward (forward), a lower bound - the anchor to start from and go forward; if unset, defaults to the oldest version known to the catalog's mutation history. A forward `sinceVersion` past the newest available version is not rejected - it simply yields an empty stream.
Index of the mutation within `sinceVersion` to anchor the search at (inclusive). A version's mutations are numbered from 1 upward; the transaction header itself occupies index 0. If unset, no index-based filtering is applied within `sinceVersion` - all of that version's mutations are included.
Criteria mutations must match to be included (entity type, mutation kind, area, etc.). An empty list applies no criteria-based filtering.
Whether the response carries only mutation headers (`CHANGE_HEADER`, the default - proto3 zero value - when this field is left unset) or full mutation bodies (`CHANGE_BODY`). Only `CHANGE_BODY` carries enough information (e.g. `mutationCount` on the transaction header) to verify a transaction was received in full.
Response to GetMutationsHistory / GetMutationsHistoryForward request. The server sends one such message per mutation - each carries exactly one `changeCapture` entry, not a batch (see the RPC's streaming semantics).
Used as response type in: EvitaSessionService.GetMutationsHistory, EvitaSessionService.GetMutationsHistoryForward
The single mutation delivered by this stream message.
Request for a single bounded batch of past traffic records matching the given criteria.
Used as request type in: GrpcEvitaTrafficRecordingService.GetTrafficRecordingHistoryList, GrpcEvitaTrafficRecordingService.GetTrafficRecordingHistoryListReversed
Maximum number of matching traffic records to return in this response. This is a plain result cap - not page-based or offset-based pagination - and the server enforces no upper bound of its own beyond it. To continue fetching beyond this limit, issue a new request with `criteria.sinceSessionSequenceId` and `criteria.sinceRecordSessionOffset` set to the position right after the last record already received.
The criteria of the traffic recording, allowing constraints on the returned records. If unset, no filters are applied and all recorded traffic (up to `limit`) is eligible.
Response to GetTrafficHistoryList request.
Used as response type in: GrpcEvitaTrafficRecordingService.GetTrafficRecordingHistoryList, GrpcEvitaTrafficRecordingService.GetTrafficRecordingHistoryListReversed
The matching traffic records, up to the requested `limit`.
Response to StartTrafficRecording, StopTrafficRecording, and ExportTrafficRecording requests.
Used as response type in: GrpcEvitaTrafficRecordingService.ExportTrafficRecording, GrpcEvitaTrafficRecordingService.StartTrafficRecording, GrpcEvitaTrafficRecordingService.StopTrafficRecording
The status of the recording task
Request to activate a catalog.
Used as request type in: EvitaService.ActivateCatalog, EvitaService.ActivateCatalogWithProgress
Name of the catalog to activate.
The catalog-level `COMPONENT_ACTIVITY` component - how much write work this catalog has done, and how fast it is doing it right now. Every figure is a counter read or an already-sampled rate; nothing here touches the file system. The counters are PROCESS-SCOPED, and `countingSince` is what makes them readable. They start at zero when the catalog is loaded and are not persisted, so a client that reads `transactionsCommitted` as "transactions this catalog has ever seen" is wrong by everything that happened before that load. Difference two polls to get an exact rate over the interval between them; use `countingSince` for a lifetime average that is actually true. They do survive a catalog generation switch - a commit replaces the catalog instance but not the pipeline behind it. The rates are short-window and DECAY while nothing is written, so a catalog written hard for a minute and then left alone converges on zero instead of reporting that minute's load forever. Not delivered for an unusable catalog, and reported as `AVAILABILITY_FEATURE_DISABLED` for a catalog in `WARMING_UP`: writes in that state bypass the transactional pipeline entirely, so every counter here would read zero however hard the catalog is being ingested into.
Used in:
Transactions appended to the write-ahead log since `countingSince` - the point of no return, after which the transaction is committed whatever happens downstream.
Transactions discarded at session close because the session was marked rollback-only; these never reach the pipeline at all.
Transactions rejected by conflict resolution because another transaction had already claimed one of their conflict keys.
Mutations carried by the committed transactions - the count the transaction declares, not the local mutations they expand into.
Bytes those transactions appended to the write-ahead log.
Versions accepted but not yet visible to readers, i.e. `lastAssignedCatalogVersion - lastFinalizedCatalogVersion` of `GrpcCommitPipelineStatistics`. Repeated here on purpose, so a client polling only this component can tell a busy catalog from a backed-up one without requesting a second one.
Recent commit rate, decayed towards zero while the catalog is idle (transactions/s).
Recent mutation rate, on the same window (mutations/s).
Recent write-ahead log growth rate, on the same window (bytes/s).
The instant the counters above were zeroed - never before this catalog was opened.
Mutation is responsible for adding one or more currencies to a `EntitySchema.currencies` in `EntitySchema`.
Used in:
Set of all currencies that could be used for prices in entities of this type.
Mutation is responsible for adding one or more modes to a `CatalogSchema.catalogEvolutionMode` in `CatalogSchema`.
Used in:
Set of allowed catalog evolution modes. These allow to specify how strict is evitaDB when unknown information is presented to her for the first time. When no evolution mode is set, each violation of the `CatalogSchema` is reported by an error. This behaviour can be changed by this evolution mode, however.
Mutation is responsible for adding one or more modes to a `EntitySchema.evolutionMode` in `EntitySchema`.
Used in:
Set of allowed evolution modes. These allow to specify how strict is evitaDB when unknown information is presented to her for the first time. When no evolution mode is set, each violation of the `EntitySchema` is reported by an error. This behaviour can be changed by this evolution mode, however.
Mutation is responsible for adding one or more locales to a `EntitySchema.locales` in `EntitySchema`.
Used in:
Set of all locales that could be used for localized `AttributeSchema` or `AssociatedDataSchema`.
Status of the external API
Used in:
True when this API is turned on in the server configuration. An enabled API can still be briefly not ready while the server is starting up - see `ready`.
True when the API has finished initialization and is actually able to serve requests. Always false when `enabled` is false.
Base URLs the API is reachable on - one per configured host binding (`host`, plus the `exposeOn` override if set), so this commonly holds more than one URL even though the field name is singular.
Notable endpoints exposed by this API in addition to its base URLs, each entry naming the endpoint and giving its URL(s). Currently only the system API populates this list; every other API reports it empty.
Increments or decrements existing numeric value by specified delta (negative number produces decremental of existing number, positive one incrementation). Allows to specify the number range that is tolerated for the value after delta application has been finished to verify for example that number of items on stock doesn't go below zero.
Used in: ,
Unique name of the attribute. Case-sensitive. Distinguishes one associated data item from another within single entity instance.
Contains locale in case the attribute is locale specific.
Delta to change existing value by of this attribute (negative number produces decremental of existing number, positive one incrementation).
Integer delta to apply to existing value of this attribute.
Long delta to apply to existing value of this attribute.
BigDecimal delta to apply to existing value of this attribute.
Number range that is tolerated for the value after delta application has been finished to verify for example that number of items on stock doesn't go below zero.
Integer number range within which the value after delta application has to be.
Long number range within which the value after delta application has to be.
BigDecimal number range within which the value after delta application has to be.
Request to apply mutation on engine level.
Used as request type in: EvitaService.ApplyMutation, EvitaService.ApplyMutationWithProgress
Single engine level mutation to be applied.
Streamed progress report for any of evitaDB's long-running catalog-lifecycle operations that support progress tracking (apply mutation, rename, replace, make mutable/immutable/alive, duplicate, activate, deactivate - see the `*WithProgress` RPCs on `EvitaService`). One or more intermediate messages are streamed as the operation advances, followed by exactly one final message with `progressInPercent` set to 100.
Used as response type in: EvitaService.ActivateCatalogWithProgress, EvitaService.ApplyMutationWithProgress, EvitaService.DeactivateCatalogWithProgress, EvitaService.DuplicateCatalogWithProgress, EvitaService.MakeCatalogAliveWithProgress, EvitaService.MakeCatalogImmutableWithProgress, EvitaService.MakeCatalogMutableWithProgress, EvitaService.RenameCatalogWithProgress, EvitaService.ReplaceCatalogWithProgress
Progress of the tracked operation (percent, 0-100). Intermediate updates are throttled (only sent on an increase, at most once per second); the final message of the stream always carries 100.
Catalog version reached by the operation. Set only on the final message (`progressInPercent` = 100), and only if the operation produced a catalog version (i.e. relates to a catalog rather than being purely engine-level); unset on every intermediate update.
Catalog schema version reached by the operation. Set only on the final message (`progressInPercent` = 100), and only if the operation produced a catalog schema version (i.e. relates to a catalog rather than being purely engine-level); unset on every intermediate update.
This is the definition object for associated data that is stored along with entity. Definition objects allow to describe the structure of the entity type so that in any time everyone can consult complete structure of the entity type. Associated data carry additional data entries that are never used for filtering / sorting but may be needed to be fetched along with entity in order to present data to the target consumer (i.e. user / API / bot). Associated data may be stored in slower storage and may contain wide range of data types - from small ones (i.e. numbers, strings, dates) up to large binary arrays representing entire files (i.e. pictures, documents).
Used in:
Contains unique name of the model. Case-sensitive. Distinguishes one model item from another within single entity instance.
Contains description of the model is optional but helps authors of the schema / client API to better explain the original purpose of the model to the consumers.
Deprecation notice contains information about planned removal of this entity from the model / client API. This allows to plan and evolve the schema allowing clients to adapt early to planned breaking changes. If notice is `null`, this schema is considered not deprecated.
Data type of the associated data. Must be one of Evita-supported values. Internally the type is converted into Java-corresponding data type. The type may be scalar type or may represent complex object type (JSON).
Localized associated data has to be ALWAYS used in connection with specific `Locale`. In other words - it cannot be stored unless associated locale is also provided.
When associated data is nullable, its values may be missing in the entities. Otherwise, the system will enforce non-null checks upon upserting of the entity.
Contains associated data name converted to different naming conventions.
Contains the per-associated-data override of the conflict resolution granularity. Defaults to inherited (follow the resolved conflict resolution).
The cardinality readings of one attribute index within one entity index.
Used in:
Name of the indexed attribute.
Name of the reference the attribute is defined on. Unset for an entity-level attribute - one defined directly on the entity rather than on one of its references.
Locale of the indexed values. Unset when the attribute is not localized; a localized attribute has one index per locale and each is reported separately, because their selectivities genuinely differ.
Which of the attribute's index structures these readings describe.
How many distinct values the structure holds (values).
How many records those values cover between them (records). `recordsCovered` divided by `distinctValueCount` is the average number of records sharing one value, and a large quotient is what "this index is not earning its keep" looks like.
Attribute element is a part of the sortable compound. It defines the attribute name, the direction of the sorting and the behaviour of the null values. The attribute name refers to the existing attribute defined in the schema.
Used in: ,
Name of the existing attribute in the same schema.
Direction of the sorting.
Behaviour of the null values.
An optional acceleration an attribute's filter index maintains on top of the plain index that `filterable` or `unique` already provides. Each member costs extra memory and extra write-path work, which is why none of them is implied by those declarations - an attribute declares the ones its workload actually queries and nothing else. A capability is always declared together with filterability and per scope, carried by `GrpcScopedAttributeFilterAccelerators`. "Accelerated but not filterable" is not a representable state - a mutation arriving over the wire that names a scope the attribute is not filterable in is refused by the server. The members name the capability the index *gains*, never the physical structure that provides it - the structure is an engine implementation detail that may change without the schema changing.
Used in:
Default value, never sent by the server and rejected when received. Absence of an acceleration is expressed by an empty `accelerators` list, not by this member, so an explicit zero on the wire is always a client mistake.
Substring matching against the attribute's values is served from a dedicated index instead of scanning every distinct value of the attribute. It accelerates `attributeContains` and `attributeEndsWith`, and only those two. `attributeStartsWith` is deliberately excluded - it already has an anchored range-scan fast path over the shared value tree, so routing it through this index would trade a cheap prefix walk for a more expensive one. Declaring the capability never changes what a query matches; only the way candidates are found differs. Patterns shorter than three code points cannot be decomposed into a trigram and fall back to the ordinary value scan, so an attribute queried only with one- or two-character patterns gains nothing while still paying the cost. Allowed only on attributes of type `String` or `String[]`; any other type is refused at schema-mutation time. Enabling it on an entity collection that already holds data is refused as well - the index is built as entities are indexed, so the accelerator must be declared before the data is inserted.
Which of an attribute's index structures a cardinality reading describes. One attribute can be indexed several ways at once - a filterable AND sortable attribute has both a filter and a sort index - and their distinct-value counts are not interchangeable, so a reading always names the structure it came from. The chain index used for ordered references has no value dimension at all: it stores predecessor links between records rather than values, so "distinct values" is not a question that can be asked of it and it is deliberately absent here.
Used in:
Default value, never sent by the server. Every reported cardinality carries an explicit structure.
The unique index - a value maps to at most one record.
The filter index - the inverted index used to resolve equality, prefix and range predicates.
The sort index - records ordered by their attribute value.
Enum specifies different modes for reference attributes inheritance in reflected schema.
Used in: , ,
* Inherit all attributes by default except those listed in the attribute inheritance filter array.
* Do not inherit any attributes by default except those listed in the attribute inheritance filter array.
Mutation of a single attribute.
Used in:
The mutation to apply.
Increments or decrements existing numeric value by specified delta (negative number produces decremental of existing number, positive one incrementation).
Upsert attribute mutation will either update existing attribute or create new one.
Remove attribute mutation will drop existing attribute - ie.generates new version of the attribute with tombstone on it.
This is the definition object for attributes that are stored along with entity. Definition objects allow to describe the structure of the entity type so that in any time everyone can consult complete structure of the entity type. Definition object is similar to Java reflection process where you can also at any moment see which fields and methods are available for the class. Entity attributes allows defining set of data that are fetched in bulk along with the entity body. Attributes may be indexed for fast filtering (`AttributeSchema.filterable`) or can be used to sort along (`AttributeSchema.sortable`). Attributes are not automatically indexed in order not to waste precious memory space for data that will never be used in search queries. Filtering in attributes is executed by using constraints like `and`, `not`, `attributeEquals`, `attributeContains` and many others. Sorting can be achieved with `attributeNatural` or others. Attributes are not recommended for bigger data as they are all loaded at once requested. Large data that are occasionally used store in `associatedData`.
Used in: ,
Contains unique name of the model. Case-sensitive. Distinguishes one model item from another within single entity instance.
When this attribute schema belongs to a catalog - it is global and can have globally unique attributes enforced across whole catalog.
Contains description of the model is optional but helps authors of the schema / client API to better explain the original purpose of the model to the consumers.
Deprecation notice contains information about planned removal of this entity from the model / client API. This allows to plan and evolve the schema allowing clients to adapt early to planned breaking changes. If notice is `null`, this schema is considered not deprecated.
When attribute is unique it is automatically filterable, and it is ensured there is exactly one single entity having certain value of this attribute among other entities in the same collection. As an example of unique attribute can be EAN - there is no sense in having two entities with same EAN, and it's better to have this ensured by the database engine. Deprecated since 2024.12 - deprecated in favor of `uniqueInScopes`
When attribute is unique globally it is automatically filterable, and it is ensured there is exactly one single entity having certain value of this attribute in the entire catalog. The type of the unique attribute must implement the `Comparable` interface. As an example of unique attribute can be URL - there is no sense in having two entities with same URL, and it's better to have this ensured by the database engine. Deprecated since 2024.12 - deprecated in favor of `uniqueGloballyInScopes`
When attribute is filterable, it is possible to filter entities by this attribute. Do not mark attribute as filterable unless you know that you'll search entities by this attribute. Each filterable attribute occupies (memory/disk) space in the form of index. When attribute is filterable, extra result `attributeHistogram` can be requested for this attribute. Deprecated since 2024.12 - deprecated in favor of `filterableInScopes`
When attribute is sortable, it is possible to sort entities by this attribute. Do not mark attribute as sortable unless you know that you'll sort entities along this attribute. Each sortable attribute occupies (memory/disk) space in the form of index. Deprecated since 2024.12 - deprecated in favor of `sortableInScopes`
When attribute is localized, it has to be ALWAYS used in connection with specific `Locale`.
When attribute is nullable, its values may be missing in the entities. Otherwise, the system will enforce non-null checks upon upserting of the entity.
Representative flag marks the attribute as one of the most important attributes in the entity, or when used on a reference-level attribute schema, it marks attributes distinguishing duplicated references to the same entity and is a key attribute for creating distinct indexes for such references. In overall, representative attributes should be used in developer tools along with the entity's primary key to describe the entity or reference to that entity. If the flag is used correctly, it can be very helpful to developers in quickly finding their way around the data. There should be very few representative attributes in the entity / reference type, and the ones with uniqueness significance are usually the best to choose.
Data type of the attribute. Must be one of Evita-supported values. Internally the scalar is converted into Java-corresponding data type.
Default value is used when the entity is created without this attribute specified. Default values allow to pass non-null checks even if no attributes of such name are specified.
Determines how many fractional places are important when entities are compared during filtering or sorting. It is significant to know that all values of this attribute will be converted to `Int`, so the attribute number must not ever exceed maximum limits of `Int` type when scaling the number by the power of ten using `indexedDecimalPlaces` as exponent.
Contains attribute name converted to different naming conventions.
Contains true if the attribute was inherited from the original object via reflected reference relation
When attribute is unique it is automatically filterable, and it is ensured there is exactly one single entity having certain value of this attribute among other entities in the same collection. As an example of unique attribute can be EAN - there is no sense in having two entities with same EAN, and it's better to have this ensured by the database engine.
When attribute is unique globally it is automatically filterable, and it is ensured there is exactly one single entity having certain value of this attribute in the entire catalog. The type of the unique attribute must implement the `Comparable` interface. As an example of unique attribute can be URL - there is no sense in having two entities with same URL, and it's better to have this ensured by the database engine.
When attribute is filterable, it is possible to filter entities by this attribute. Do not mark attribute as filterable unless you know that you'll search entities by this attribute. Each filterable attribute occupies (memory/disk) space in the form of index. When attribute is filterable, extra result `attributeHistogram` can be requested for this attribute.
When attribute is sortable, it is possible to sort entities by this attribute. Do not mark attribute as sortable unless you know that you'll sort entities along this attribute. Each sortable attribute occupies (memory/disk) space in the form of index.
Contains the per-attribute override of the conflict resolution granularity. Defaults to inherited (follow the resolved conflict resolution).
The optional accelerations the attribute's filter index maintains, per scope. Only scopes the attribute has a filter index in - i.e. is filterable or unique in - may appear here. An empty list - which is what an older server sends - means no acceleration anywhere.
Mutation of an attribute schema.
Used in:
Type of the mutation.
Mutation is responsible for setting up a new `AttributeSchema` in the `EntitySchema`.
Mutation is responsible for modifying a default value of an existing `AttributeSchema` in the `EntitySchema`.
Mutation is responsible for modifying a deprecation notice of an existing `AttributeSchema` in the `EntitySchema`.
Mutation is responsible for modifying a description of an existing `AttributeSchema` in the `EntitySchema`.
Mutation is responsible for renaming an existing `AttributeSchema` in `EntitySchema` or `GlobalAttributeSchema` in `CatalogSchema`.
Mutation is responsible for modifying a type of an existing `AttributeSchema` in the `EntitySchema`.
Mutation is responsible for removing an existing `AttributeSchema` in the `EntitySchema` or `GlobalAttributeSchema`
Mutation is responsible for setting value `AttributeSchema.filterable` in `EntitySchema`.
Mutation is responsible for setting value `AttributeSchema.localized` in `EntitySchema`.
Mutation is responsible for setting value `AttributeSchema.nullable` in `EntitySchema`.
Mutation is responsible for setting value `AttributeSchema.representative` in `EntitySchema`.
Mutation is responsible for setting value `AttributeSchema.sortable` in `EntitySchema`.
Mutation is responsible for setting value `AttributeSchema.unique` in `EntitySchema`.
Mutation is responsible for introducing a `GlobalAttributeSchema` into an `EvitaSession`.
Mutation is responsible for setting value `AttributeSchema.conflictResolutionOverride` in `EntitySchema`.
Mutation is responsible for setting the filter accelerators of an `AttributeSchema` in `EntitySchema`.
Defines the type of the attribute schema
Used in:
attribute schema is GlobalAttributeSchemaContract
attribute schema is EntityAttributeSchemaContract
attribute schema is AttributeSchemaContract
Represents constant or "special" value attribute can have (or has it implicitly, e.g. missing value is represented `null` that is not directly comparable).
Used in: ,
Represents missing value.
Represents existing (not-null) value.
Wrapper for representing an array of AttributeSpecialValue enums.
Used in:
The individual AttributeSpecialValue values, in their original order.
This enum represents the uniqueness type of an `AttributeSchema`. It is used to determine whether the attribute value must be unique among all the entity attributes of this type or whether it must be unique only among attributes of the same locale.
Used in: , , , , ,
The attribute is not unique (default).
The attribute value must be unique among all the entities of the same collection.
The localized attribute value must be unique among all values of the same `Locale` among all the entities using of the same collection.
Request to back up a catalog and stream the backup file to the client.
Used as request type in: EvitaSessionService.BackupCatalog, EvitaSessionService.BackupCatalogWithProgress
The moment in time to back up the catalog's state to. If unset, defaults to the current moment (subject to being overridden by `catalogVersion`, see below).
True, if the WAL should be included in the backup. Use false if you want to restore catalog in exact state as it was at the pastMoment.
Precise catalog version to create the backup for. If unset, defaults to the latest version - or, when `pastMoment` is set, the version resolved from `pastMoment`. When this field is set, `pastMoment` is ignored regardless of whether it is also set.
Response to a catalog backup request.
Used as response type in: EvitaSessionService.BackupCatalog, EvitaSessionService.BackupCatalogWithProgress
Handle to the asynchronous backup task; use it to poll or stream the task's progress and, once finished, retrieve the resulting backup file.
Representation of Java's BigDecimal class with arbitrary precision.
Used in: , , , , , , , ,
The decimal value serialized as a string in the canonical form produced by `BigDecimal#toString()`, with the exponent marker lower-cased and its `+` sign stripped (e.g. `2.5e8` rather than `2.5E+8`). Preserves the original scale so the value round-trips exactly.
Wrapper for representing an array of BigDecimals.
Used in: ,
The individual BigDecimal elements, in their original order.
Representation of BigDecimalNumberRange structures. At least one of `from`/`to` should be set; if both are absent, the range decodes to the degenerate range `[0,0]` rather than being unbounded in both directions.
Used in: , , ,
The inclusive lower bound of the range. If unset (while `to` is set), the range is unbounded below.
The inclusive upper bound of the range. If unset (while `from` is set), the range is unbounded above.
The number of fractional digits retained (rounded half-up) when comparing values against this range: both bounds and the compared value are scaled to this precision first, so digits beyond it are ignored for range-membership comparisons.
Wrapper for representing an array of BigDecimalNumberRanges.
Used in: ,
The individual BigDecimalNumberRange elements, in their original order.
Response carries entities in a binary format and is part of the PRIVATE API that is used by Java driver. The client that receives the binary data must know how to deserialize them using Kryo deserializers which are internal to the evitaDB (and even if they had been public they could not have been used because Kryo is not ported to other platforms than Java). The response is triggered by BinaryForm query requirement.
Used in: , ,
Type of entity. Entity type is main sharding key - all data of entities with same type are stored in separated collections. Within the entity type entity is uniquely represented by primary key.
Unique Integer positive number representing the entity. Can be used for fast lookup for entity (entities). Primary key must be unique within the same entity type.
Contains version of this entity schema and gets increased with any entity type update. Allows to execute optimistic locking i.e. avoiding parallel modifications.
Serialized representation of the entity body.
Serialized representation of entity attributes.
Serialized representation of entity associated data.
Serialized representation of entity prices.
Serialized representation of entity references.
Wrapper for representing an array of booleans.
Used in: ,
The individual boolean elements, in their original order.
One index, as described by an index browse. Where `GrpcCollectionIndexSummary` answers how many indexes of each type a collection holds, this answers which ones - one page at a time. A count of forty thousand indexes of one type tells an operator that something is wrong but not which reference caused it; this is the drill-down that does. One message describes both an entity collection's indexes and the ones a catalog holds itself, so a client renders one table and holds one code path. Which of the two a row is, is stated by `entityType`; what a catalog index does not have is stated by leaving fields unset rather than by a stand-in value. An index is identified by `entityType` together with `indexPrimaryKey`, and by nothing else on this message - the handle alone identifies an index only within its owner, so a catalog index and some collection's first index both answer to `0`. Everything else is for a human to read: in particular `referenceName` and `discriminatorPrimaryKey` do not identify an index between them, because a reference whose targets are told apart by representative attribute values has one index per distinct value set, all sharing one reference name and one target primary key. Display `discriminator`, but compare the identity pair. - a catalog index carries no type and no discriminator in any of its three renderings, - global indexes carry no discriminator at all, and neither projection, - the per-reference-type index types carry a reference name and no primary key - one index covers the whole reference, - the per-referenced-entity index types carry both, plus whatever else distinguishes the target.
Used in:
Type of this index. Unset when the index is one the catalog holds itself - see `GrpcIndexCardinality.indexType` for why no value of this enum describes one.
Scope this index belongs to.
Name of the reference this index is bound to. Unset for a global index, which is bound to no reference at all rather than to an unnamed one. Not unique on its own - see the message comment.
Primary key of the referenced entity this index is bound to. Unset when the index covers a whole reference type rather than one target entity - the two cases are distinguished by which of them `indexType` names. Not unique on its own - see the message comment.
How many entities this index covers (entities). A cardinality reading of the index's primary-key bitmap, never a walk of its contents. It counts entities, and is not a stand-in for how much memory the index occupies. Heap is driven by how many attributes are indexed and how many distinct values they hold, which no entity count can see: on a measured production catalog a global index ran about 8.7 KB per entity against about 2.4 KB for a large per-referenced- entity one. No memory figure is derived from this number anywhere in the API, deliberately - that ratio is a property of a catalog's own schema and data, so any coefficient applied to it would be wrong, in an unknown direction, on every other dataset. Unset for an index the catalog holds itself, which has no primary-key bitmap to read a cardinality off.
Stable rendering of everything that distinguishes this index from its siblings of the same type and scope, including the representative attribute values the two fields above omit. Unset for a global index, which has no siblings to be told apart from. Treat it as opaque: display it, do not parse it.
Identity of this index within its owner, and the handle to pass back - together with `entityType` - when asking about one index in particular. Treat it as an opaque handle: it means nothing on its own, and the same value under another owner is another index entirely. The two owners derive it differently, which a client holding a handle across a removal can observe. A collection assigns it from a forward-only sequence whose high-water mark is persisted, so it is never reused and a row held across the index's removal can only fail to resolve, never resolve to a different index. The catalog derives it from the index's scope, so it denotes the same logical index whether or not that index exists right now - the archived catalog index is created lazily, so its handle can fail to resolve and later start resolving, always to the index it already denoted.
Name of the entity collection holding this index. Unset for an index the catalog holds itself, which belongs to no collection rather than to an unnamed one. Carried on the row rather than left to the client's memory of what it asked for, so a client concatenating a catalog browse and a collection browse into one table still has the other half of each row's identity.
How many executed query plans have chosen this index as part of their winning target index set. It counts chosen, not consulted. Planning also probes candidate indexes that lose the cost comparison, reaches a collection's super price index from a reduced-index plan, and pulls referenced-entity indexes to enrich what is fetched - none of that is counted here. The reading means "this index was the filtering backbone of an executed query", which is what makes it actionable; counting every consultation would inflate the losers and say nothing about what to drop. Counted since the server loaded the catalog, and never persisted - see `updateCount`.
How many entity mutations have acquired this index for modification - one increment per entity mutation per index, never per attribute write. It counts work performed, including work a rollback later undoes: the increment happens when the mutation finishes applying, before the commit-or-rollback decision, because a rolled-back transaction still paid the index- maintenance cost and this reading measures that cost rather than surviving state. A global index is acquired by essentially every entity mutation, so its reading is close to the collection's total mutation count. That is accurate rather than misleading - a global index is never a drop candidate. The actionable readings are the ones on reduced indexes, which are acquired only when genuinely touched. Counted since the server loaded the catalog, and never persisted: both counters and both stamps reset on a catalog load, because their operational use is a rate over an observation window, which persisting them would not improve, while a hot mutable value in an index's manifest would cost a rewrite on every commit. Read a pair of samples, not one absolute number.
When the last query that chose this index was planned. Unset when no query has chosen it since the catalog was loaded - which is a statement about the observation window rather than about the index's whole life.
When the last entity mutation that acquired this index finished applying. Unset when none has since the catalog was loaded - see `lastQueriedAt`.
Whether the readings above were taken at all. False on a server started with `server.usageStatisticsTracking: false`, which allocates no activity holder per index and lets neither the query nor the write path reach for one. A client MUST branch on this before rendering a zero. "Not measured" and "never queried" are opposite findings - only the second one says an index can be dropped - and a zero shown beside a live window asserts the second when the truth is the first. Render the absence of measurement instead, and say so. Presence-tracked on purpose. A server predating this field sends nothing, and that silence must NOT be read as "not measured": such a server had no switch to turn counting off, so it always measured and its counts are real. Absent therefore decodes as `true`. Only an explicit `false` means the operator switched counting off.
When observation of this index began - the start of the window the two counters and the two stamps above are read against. A server that knows this field always sets it: an index is observed from the moment it exists, so there is no "not yet" case. The only absence a client can encounter is a server predating the field, and it must then treat the window as unknown rather than substitute any instant for it - the epoch would fabricate a decades-long window, "now" a zero-length one. It is a property of this index rather than of the catalog: an index the server loaded the catalog with reads the load, while one created hours later reads its own creation, because it was not observable before it existed. That is what makes the two readings honest - `queryCount / (now - observedSince)` is a lifetime average rate, and a zero count qualifies as "not once in this long" instead of as a bare zero a client cannot weigh.
Enum specifying the type of response that is sent to the subscriber.
Used in: ,
The response contains only the acknowledgement of the subscription.
The response contains the change event that was captured.
The response contains the heartbeat event.
In EvitaDB we define only one-way relationship from the perspective of the entity. We stick to the ERD modelling <a href="https://www.gleek.io/blog/crows-foot-notation.html">standards</a> here.
Used in: , , , , ,
No cardinality specified.
Relation may be missing completely, but if it exists - there is never more than single relation of this type.
There is always single relation of this type.
Relation may be missing completely, but there may be also one or more relations of this type.
There is always at least one relation of this type, but there may be also more than one.
There is always at least one relation of this type, but there may be also more than one. When there is more than one, they may refer the same target entity (and are distinguished by reference attributes)
There is always at least one relation of this type, but there may be also more than one. When there is more than one, they may refer the same target entity (and are distinguished by reference attributes)
Evolution mode allows to specify how strict is evitaDB when unknown information is presented to her for the first time. When no evolution mode is set, each violation of the EntitySchema is reported by an exception. However, this behaviour can be changed by this evolution mode.
Used in: , ,
When new entity is inserted and no collection of its entity type exists, it is silently created with empty schema and with all Evolution modes allowed.
The `COMPONENT_IDENTITY` component - who this catalog is and what mode it is running in. Always present on both catalog-level and collection-level snapshots, whether or not it was requested: no other component can be interpreted without knowing which catalog produced it, at which version, and whether that catalog is usable. For a catalog that could not be loaded (`unusable` is true) most fields fall back: `catalogId` is unset, `catalogState` reads `CORRUPTED` or `UNKNOWN_CATALOG_STATE`, `catalogVersion` and `entityCollectionCount` read `-1` and `transactional` / `goingLive` read false. `catalogName` and `readOnly` stay valid - they are known without loading anything.
Used in: ,
Unique identifier of the catalog. Unset when the catalog is unusable and its id could not be determined.
The catalog's unique name, used to address it via the API. Always present, even for a corrupted catalog.
Current lifecycle state of the catalog, or `UNKNOWN_CATALOG_STATE` when it could not be determined.
Current version of the catalog, incremented on every commit. `-1` when the catalog is unusable.
True when the catalog rejects mutations.
True when the catalog is corrupted and could not be loaded.
True when writes go through the transactional pipeline. False in `WARMING_UP`, where writes are applied in bulk with no transactional guarantees.
True while the catalog is transitioning out of `WARMING_UP` into `ALIVE`.
Number of entity collections the catalog holds; `-1` when the catalog is unusable. Reported explicitly rather than derived from the collection inventory, so it survives the corrupted case where that inventory is empty.
The catalog-level half of the `COMPONENT_INDEX_CARDINALITY` component - how many distinct values each of the catalog's global unique indexes holds. Unlike the collection-level half (`GrpcCollectionIndexCardinality`) this one is cheap: the number of global unique indexes is bounded by the schema (globally-unique attributes x locales), never by the catalog's data volume, and every reading is a counter maintained incrementally rather than a walk. That is why `COMPONENT_INDEX_CARDINALITY` is available at the catalog level while its collection-level half must never join a polled refresh.
Used in:
One entry per global unique index the catalog holds, in no guaranteed order. Empty when the schema declares no globally-unique attribute, or when none has been written to yet.
Fires when a catalog's local reference settles into a non-transient state on this host.
Used in:
the name of the catalog whose reference settled
the non-transient state the catalog settled into
snapshot of the engine version at emit time (correlation only - does not advance)
Fires when a catalog is fully removed from the live view on this host.
Used in:
the name of the catalog that was removed
snapshot of the engine version at emit time (correlation only - does not advance)
Represents the schema of a single catalog - the top-level container that groups related entity collections together (analogous to a database / schema in a relational system). Holds the catalog name, its schema version, optional description, evolution mode settings, catalog-wide (global) attributes shared across entity types, name variants and the conflict resolution policy inherited by entity schemas that don't override it.
Used in: ,
Contains unique name of the catalog. Case-sensitive. Distinguishes one catalog item from another within single entity instance.
Contains version of this catalog schema and gets increased with any entity type update. Allows to execute optimistic locking i.e. avoiding parallel modifications.
Contains description of the model is optional but helps authors of the schema / client API to better explain the original purpose of the model to the consumers.
set of evolution modes that allow to specify how strict is evitaDB when unknown information is presented to her for the first time. When no evolution mode is set, each violation of the catalog schema is reported by an exception. This behaviour can be changed by this evolution mode, however.
Contains index of generally (catalog-wide) shared `AttributeSchema` that could be used as attributes of any entity type that refers them. These attributes cannot be changed from within the entity schema. Entity schemas will not be able to define their own attribute of same name that would clash with the global one (they may only reference the attributes with the same name from the catalog schema). There may be entities that won't take advantage of certain global attributes (i.e. it's not guaranteed that all entity types in catalog have all global attributes). The "catalog-wide" unique attributes allows Evita to fetch entity of any (and up-front unknown) entity type by some unique attribute value - usually URL.
Contains catalog name converted to different naming conventions.
Contains the catalog-level conflict resolution setting. When not set (absent), the catalog schema inherits the resolved conflict resolution from the transaction options.
Fires when a catalog's schema version increases on this host (coalesced once per session/transaction). See HostSystemEvent.CatalogSchemaUpdated.
Used in:
the name of the catalog whose schema version increased
the new (current) catalog schema version on this host
snapshot of the engine version at emit time (correlation only - does not advance)
Indicates actual state in which Evita operates. See detailed information for each state.
Used in: , , , , ,
Initial state of the Evita catalog. This state has several limitations but also advantages. This state requires single threaded access - this means only single thread can read/write data to the catalog in this state. No transactions are allowed in this state and there are no guarantees on consistency of the catalog if any of the WRITE operations fails. If any error is encountered while writing to the catalog in this state it is strongly recommended discarding entire catalog contents and starts filling it from the scratch. Writing to the catalog in this phase is much faster than with transactional access. Operations are executed in bulk, transactional logic is disabled and doesn't slow down the writing process. This phase is meant to quickly fill initial state of the catalog from the external primary data store. This state is also planned to be used when new replica is created and needs to quickly catch up with the master.
Standard "serving" state of the Evita catalog. All operations are executed transactionally and leave the date in consistent state even if any error occurs. Multiple readers and writers can work with the catalog simultaneously.
State signalizing that evitaDB engine was not able to consistently open and load this catalog from the file system.
State signalizing that evitaDB engine didn't load this catalog from the file system, but is present in the persistence storage. Catalog might be loaded into memory later on demand and start to process requests.
State signalizing that evitaDB engine is transitioning catalog from `WARMING_UP` to `ALIVE` state. Until the transition is fully completed, the catalog is not able to serve any requests.
State signalizing that evitaDB engine is loading catalog from the file system to the memory and performing initialization of the catalog. The catalog is not able to serve any requests until the initialization is fully completed.
State signalizing that evitaDB engine is deactivating the catalog. When the operation is completed, the catalog is moved to `INACTIVE` state.
State signalizing that evitaDB engine is creating a new catalog. The catalog is not able to serve any requests until the creation is fully completed.
State signalizing that evitaDB engine is deleting the catalog. When the operation is completed, the catalog is removed from the file system and is no longer available.
State signalizing that a catalog previously registered with the engine no longer has an on-disk folder. The engine records this divergence via `MarkCatalogMissingMutation` so it can be diagnosed and later recovered via auto-discovery or operator action.
State signalizing that the catalog's on-disk storage protocol is older than the engine supports. Reads and writes are refused until the catalog has been upgraded via `UpgradeCatalogFormatMutation`.
State signalizing that the catalog is currently being upgraded from an older storage protocol to the one the engine supports. Transient state entered while an `UpgradeCatalogFormatMutation` is running; the completion phase returns the catalog to its prior operational state.
Unknown state of the catalog. Used when catalog is corrupted.
Aggregates basic data about the catalog and entity types stored in it.
Used in:
unique identifier of the catalog
The catalog's unique name, used to address it via the API.
true if the catalog is corrupted (other data will be not available) Deprecated since 2025.7 - deprecated in favor of `catalogState` (compare against `CORRUPTED`)
Current lifecycle state of the catalog. Reflects `CORRUPTED` when the catalog failed to load consistently, or `UNKNOWN_CATALOG_STATE` if the state could not be determined.
version of the catalog, -1 for corrupted catalog
total number of records in the catalog, -1 for corrupted catalog
total number of indexes in the catalog, -1 for corrupted catalog
total size of the catalog on disk in bytes
statistics for each entity collection in the catalog, empty array for corrupted catalog
true if the catalog is read-only, false otherwise
true if the catalog is unusable, false otherwise
Independently selectable parts of a catalog or entity collection statistics snapshot. A client names the components it wants and the engine computes only those - a component that was not asked for is never computed, and its sub-message is absent from the response with no status entry. A component may exist at the catalog level, at the entity collection level, or at both. The catalog level reports aggregates only and never breaks them down per collection, so that its response stays a fixed size no matter how many collections the catalog holds; anything about one collection is fetched by naming that collection. Requesting a component at a level where it does not exist is an error, not a silently empty result.
Used in: , , ,
Default value, never valid in a request. Naming it is rejected with an error rather than silently ignored, so a client that forgot to fill the component list is told instead of receiving an identity-only response.
Catalog id, name, state, version, read-only / unusable flags and transactional capabilities. Always delivered whether or not it was requested - no other component can be interpreted without knowing which catalog produced it and whether that catalog is usable. Available at both levels.
Total / live / archived entity counts. The catalog level sums the per-collection counters, the collection level reports the counters of the named collection. Available at both levels.
Maps to a different sub-message at each level: at the catalog level it is the *inventory* of entity collections (which collections exist, and their entity type primary keys) carrying no statistics at all, while at the collection level it is the header counters of the named collection.
Number of sessions currently open against the catalog, split into read-only and read-write. Sessions are opened against a catalog, never against a collection - catalog level only.
The four commit pipeline version watermarks and the lags between them. The pipeline is catalog-wide - catalog level only.
Transaction, mutation and write-ahead log counters together with their short-window rates. Transactions span the whole catalog - catalog level only.
Disk footprint broken into the classes that have different remedies - live bytes, waste, write-ahead log, files awaiting deletion, bootstrap and the unaccounted remainder. Available at both levels, and the only component still delivered for a catalog that could not be loaded, because file lengths are readable regardless.
Storage-part histogram - where the bytes actually go, per storage-part type. The catalog level covers the catalog's own data store (schemas, catalog indexes), the collection level the named collection's data store. There is deliberately no cross-collection sum. Available at both levels.
Active record share, and whether the data store already satisfies the compaction predicate. Available at both levels; the configured thresholds driving that predicate are catalog-wide and reported at the catalog level only.
Time-travel window, retained write-ahead log files and the awaiting-deletion breakdown. The write-ahead log is catalog-wide - catalog level only.
Checkpoint cadence, fence depth and files forced - how much replay a crash would cost right now. A property of the catalog's write-ahead log - catalog level only.
Index counts. The catalog level reports the plain total, which every collection answers from a map size; the breakdown by index kind and scope walks the index keys and is therefore collection level only. Available at both levels, with different detail at each.
Distinct values and records covered per index. Expensive - never part of a polled refresh. Collection level only, because a catalog-wide form would mean paying that cost for every collection of the catalog at once.
Pending (not yet flushed) state, and the in-memory history retained for sessions that started long ago. Available at both levels.
A component-selected snapshot of one catalog's statistics. Every component the caller did not request is absent here *and* absent from `componentStatus`; every component it did request has a status entry saying whether it was delivered and, if not, why. Without that distinction a client cannot tell an unrequested component from one the engine could not compute, which is how a corrupted catalog ends up rendering as an empty catalog on a management screen. `identity` is always present, requested or not. Every other field is present only when its component was both requested and delivered - a sub-message whose fields are all zero is a real, delivered measurement, not a placeholder. Aggregates only: no component here carries a per-collection breakdown, so the size of this response does not grow with the number of collections in the catalog. The single exception is the collection *inventory*, which carries no statistics. Statistics of one collection are fetched by naming it, and the two responses are independent snapshots that may observe different catalog versions - compare `identity.catalogVersion` when that matters.
Used in: ,
Who this catalog is and what mode it runs in; always present.
The `COMPONENT_RECORD_COUNTS` component; absent unless requested and delivered.
The `COMPONENT_COLLECTIONS` component, i.e. the collection inventory; absent unless requested and delivered.
The `COMPONENT_SESSIONS` component; absent unless requested and delivered.
The `COMPONENT_COMMIT_PIPELINE` component; absent unless requested and delivered.
The `COMPONENT_STORAGE_SIZE` component; absent unless requested and delivered.
The `COMPONENT_STORAGE_COMPOSITION` component; absent unless requested and delivered.
The `COMPONENT_FRAGMENTATION` component; absent unless requested and delivered.
The `COMPONENT_HISTORY` component; absent unless requested and delivered.
The `COMPONENT_INDEX_SUMMARY` component; absent unless requested and delivered.
The `COMPONENT_VOLATILE_STATE` component; absent unless requested and delivered.
Outcome of every requested component, `COMPONENT_IDENTITY` included. Components that were not requested have no entry here at all.
The `COMPONENT_ACTIVITY` component; absent unless requested and delivered.
The `COMPONENT_DURABILITY` component; absent unless requested and delivered.
The catalog-level half of the `COMPONENT_INDEX_CARDINALITY` component; absent unless requested and delivered.
The enum defines what catalog area is covered by the capture.
Used in: ,
Changes in the schema are captured.
Changes in the data are captured.
Infrastructural mutations that are neither schema nor data.
The container type describes internal evitaDB data structures.
Used in: ,
Catalog - similar to relational database schema.
Entity - similar to relational database table (or better - set of inter-related tables).
Attribute - similar to relational database column.
Reference - similar to an unstructured JSON document in relational database column.
Price - fixed structure data type, could be represented as row in a specialized table in relational database.
Reference - similar to a foreign key in relational database or a binding table in many-to-many relationship.
Enum to specify the depth of details sent in the CDC event.
Used in: , , ,
Only the header of the event is sent.
Entire mutation triggering the event is sent. In case of mutations with the large content (associated data update), the size of the event can be significant. Consider whether you need the entire mutation or just the header.
Record for the criteria of the capture request allowing to limit mutations to specific area of interest and its properties.
Used in: , ,
The area of capture - SCHEMA, DATA or INFRASTRUCTURE. If `schemaSite`/`dataSite` below is set, it determines the effective area and this field is ignored; this field is only consulted when neither site is set, which is also the only way to select INFRASTRUCTURE (it has no site message of its own).
At most one of `schemaSite`/`dataSite` may be set. If neither is set, every mutation matching `area` passes without further site-level filtering; each set field on the chosen site message narrows the match further (see that message's field comments for what an unset field means).
Criteria for schema capture
Criteria for data capture
Record describing the location and form of the CDC data event in the evitaDB that should be captured. Every field below is an independent, optional filter (logically ANDed together when several are set); an unset/empty field imposes no restriction on that dimension.
Used in:
Restricts capture to mutations of the named entity type. If `null`, matches data mutations for any entity type.
Restricts capture to mutations of the entity with this primary key. If `null`, matches any primary key within the entity type filter above.
Restricts capture to the listed operation types. If empty, matches any operation.
Restricts capture to the listed container types (e.g. attribute, associated data, reference). If empty, matches any container type.
Restricts capture to containers with one of the listed names (e.g. attribute name, associated data name, reference name). If empty, matches containers of any name.
Enumeration of possible mutation types handled by evitaDB.
Used in: , , ,
Create or update operation - i.e. there was data with such identity before, and it was updated.
Remove operation - i.e. there was data with such identity before, and it was removed.
Delimiting operation signaling the beginning of a transaction.
Record describing the location and form of the CDC schema event in the evitaDB that should be captured. Every field below is an independent, optional filter (logically ANDed together when several are set); an unset/empty field imposes no restriction on that dimension.
Used in:
Restricts capture to schema mutations of the named entity type. If `null`, matches schema mutations for any entity type, including catalog-level schema changes (which carry no entity type of their own).
Restricts capture to the listed operation types. If empty, matches any operation.
Restricts capture to the listed container types (e.g. attribute, associated data, reference). If empty, matches any container type.
Restricts capture to containers with one of the listed names (e.g. attribute name, associated data name, reference name). If empty, matches containers of any name.
Record represents a catalog CDC event that is sent to the subscriber if it matches to the request he made.
Used in: , ,
The catalog version the operation was committed in. Strictly monotonic across the stream: ascending in a forward stream, descending in a reverse stream.
A direction-stable physical position of the underlying WAL record within its transaction, not a delivery counter: a forward stream assigns `1..mutationCount` ascending, a reverse stream assigns `mutationCount..1` descending, so the same physical record gets the same index regardless of direction - but indices are therefore NOT monotonic within a transaction when read in reverse (the transaction header is emitted at index `0`, then indices count down from `mutationCount`). Nested local mutations do not get their own index: they inherit the `(version, index)` pair of the entity mutation record they belong to, so `(version, index)` identifies a WAL record, not an individual emitted capture - an entity upsert with 5 local mutations produces 6 captures that all share the same pair. The index is advanced before criteria filtering is applied, so it stays stable and comparable across requests using different filters.
the area of the operation
the name of the entity type or its schema that was affected by the operation (if the operation is executed on catalog schema this field is null)
the primary key of the entity that was affected by the operation (null for schema operations)
The kind of change that produced this capture. Together with `area`, it determines which arm of `body` (if present) carries the payload - see the `body` oneof comment for the mapping.
Payload of the operation. Present only when the request's content mode is `CHANGE_BODY` (see `GrpcChangeCaptureContent`); a `CHANGE_HEADER` request - the proto3 default when `content` is left unset - always leaves every arm of this oneof unset. When present, exactly one arm is set, chosen by `area`/`operation`: `schemaMutation` for a SCHEMA area mutation, `entityMutation` for the top-level DATA area entity mutation, `localMutation` for a DATA area field-level mutation nested inside an entity upsert (it shares the parent entity mutation's `(version, index)` - see the `index` field comment above), `infrastructureMutation` for the INFRASTRUCTURE area transaction header.
Set for a SCHEMA area mutation. See the `body` comment above for the full arm-selection mapping.
Set for the top-level DATA area entity mutation. See the `body` comment above.
Set for a DATA area field-level mutation nested inside an entity upsert. See the `body` comment above and the `index` field comment for how it shares its parent's `(version, index)`.
Set for the INFRASTRUCTURE area transaction header. See the `body` comment above.
Represents the timestamp of the commit.
Record represents a system CDC event that is sent to the subscriber if it matches to the request he made.
Used in:
the version of the engine where the operation was performed
the index of the event within the enclosed transaction, index 0 is the transaction lead event
the operation that was performed
Body of the capture - exactly one of the two branches when present. Old clients that do not opt in to HOST never receive `hostEvent`; clients that decode an unknown oneof tag drop the body silently, which is acceptable.
Engine mutation body - durable, WAL-replicated event (ENGINE area).
Host event body (HOST area, opt-in only).
Represents the timestamp of the commit.
Criteria for filtering system CDC captures. OR-ed when multiple are provided. Default-shape divergence vs catalog stream: when criteria is empty, only ENGINE events are delivered - HOST requires explicit opt-in.
Used in:
The area of capture (system stream supports only ENGINE and HOST).
Enum describes possible classifier types used in reserved keywords listing
Used in:
* Identification of the server instance.
* Identification of the catalog.
* Identification of the entity type.
* Identification of the attribute.
* Identification of the associated data (rich content).
* Identification of the reference.
* Identification of the reference attribute.
The collection-level `COMPONENT_COLLECTIONS` component - the counters carried by one collection's storage header. The catalog-level counterpart lists only which collections exist; these are the numbers behind one of them.
Used in:
Internal primary key assigned to the entity type itself.
Version of the collection header, incremented on every flush.
Highest entity primary key assigned so far. The gap between it and the collection's record count reveals how many entities have been deleted over the collection's lifetime.
Highest entity index primary key assigned so far.
Highest internal price id assigned so far.
Highest storage key id assigned so far.
Largest single stored record ever observed in this collection (bytes). A high-water mark, not a current maximum: it is seeded from its previous value and only ever widened on flush, so removing the biggest record never lowers it. Label it "largest ever seen" wherever it is displayed.
Wall-clock time this collection's storage header was last written. The header is rewritten by every flush that changed the collection and by every compaction of it, so this answers "when did anything last change here" - the question the monotonic `version` cannot, since a version says how many times, never when. A compaction moves it forward without the data itself having changed, so it describes the storage, not a data-modification audit trail. If unset, the timestamp is unknown rather than zero: it is persisted in the collection's storage header and headers written before evitaDB 2026.3 do not carry one, so a catalog upgraded from an earlier release reports it unset for every collection until each is next flushed. Render an unset value as "unknown", never as a date.
The collection-level `COMPONENT_INDEX_CARDINALITY` component - how many distinct values each of one collection's indexes holds, next to how many records those values cover. This is the statistic that answers "is this index earning its keep, or is it three distinct values over two million records?" - a question neither the index count nor the record count can answer, because both are blind to selectivity. Paired with the schema, which a management client already holds, it turns "this collection has 412 indexes" into "these four are doing nothing". Only the schema-bounded indexes are described, and that is the whole design. A collection holds one global index per scope and one reference-type / reference-group-type index per reference schema per scope - all bounded by the schema - and one index per referenced entity, of which there can be tens of thousands. Describing the second group would make this response's size grow with the catalog's data volume, multiplied again by the attributes indexed within each one, so those indexes are counted into `omittedIndexCount` instead. Nothing is lost analytically: a per-referenced-entity index covers the records referencing one entity, so its selectivity is a property of the reference, which the reference-type index above it already summarises.
Used in:
One entry per described index, in no guaranteed order. Indexes holding no attribute index and no reference cardinality are omitted rather than reported empty.
How many of this collection's indexes were counted but not described, for the reason above (indexes). `0` means every index the collection holds is present in `indexes`.
The collection-level `COMPONENT_INDEX_SUMMARY` component - how many indexes one collection holds, broken down by type and scope. This is what turns the historically opaque single index count into something a developer can act on: forty thousand indexes of one referenced entity and forty global ones are very different situations that used to render as the same number.
Used in:
Total number of indexes in this collection (indexes).
One entry per (type, scope) pair that has at least one index. Pairs with no index are omitted rather than reported as zero.
Identification of a single entity collection - what to pass to a collection-level statistics call, plus the internal primary key the engine knows the entity type by.
Used in:
Name of the entity collection, i.e. the entity type.
Internal primary key assigned to the entity type itself.
The collection-level `COMPONENT_RECORD_COUNTS` component - how many entities one collection holds, split by scope. The catalog-level counterpart is the sum of these across all collections; see it for why `totalRecords` means live plus archived rather than live alone.
Used in:
Live plus archived entities in this collection (records).
Entities residing in the live scope (records).
Entities residing in the archive scope (records).
The collection-level `COMPONENT_STORAGE_COMPOSITION` component - where one collection's bytes go, per storage-part type. See the catalog-level counterpart for why the breakdown is measured in bytes rather than record counts.
Used in:
One entry per storage-part type present in this collection's data store.
The collection-level `COMPONENT_STORAGE_SIZE` component - the same decomposition the catalog level applies to the whole catalog, narrowed to one collection's data files. The total is measured, not derived: it is the sum of the lengths of the files whose names belong to this collection, so `sizeOnDiskInBytes` equals the sum of the other fields by construction. The write-ahead log and the bootstrap file are catalog-wide and have no per-collection counterpart, so they appear at the catalog level only.
Used in:
Measured total - the sum of the lengths of this collection's data files (bytes).
Active records in this collection's data store (bytes).
Superseded records inside it - what compacting this collection reclaims (bytes).
This collection's superseded data files that are no longer current but not yet purged (bytes). A short transient without time travel; retained for the whole history window with it, where the lever is write-ahead log retention rather than compaction, which has already run on these bytes.
Bytes among this collection's files that belong to none of the classes above (bytes).
The catalog-level `COMPONENT_COLLECTIONS` component - the inventory of the catalog's entity collections. Deliberately the only per-collection list a catalog-level snapshot carries, and it holds no statistics: it answers "which collections exist", which is what a client needs before it can ask any of them for numbers.
Used in:
One entry per entity collection the catalog holds.
Contains set of all possible close method behavior types when the session is committed/closed
Used in: , ,
Changes performed in the transaction are passed to evitaDB server, checked for conflicts and if no conflict is found the transaction is marked as completed and commit is finished. This behaviour is fastest, but does not guarantee that the changes are persisted on disk and durable. If the server crashes before the changes are written to disk, the changes are lost.
Changes performed in the transaction are passed to evitaDB server, checked for conflicts and if no conflict is found, they are written to Write Ahead Log (WAL) and transaction waits until the WAL is persisted on disk (fsynced). After that the transaction is marked as completed and commit is finished. This behaviour is slower than `WAIT_FOR_CONFLICT_RESOLUTION` but guarantees that the changes are persisted on disk and durable. The server may decide to fsync changes from multiple transactions at once, so the transaction may wait longer than necessary. This behaviour still does not guarantee that the changes will be visible immediately after the commit - because they still need to be propagated to indexes in order new data can be found by queries. This behaviour is default.
Changes performed in the transaction are passed to evitaDB server, checked for conflicts and if no conflict is found, they are written to Write Ahead Log (WAL). Then the WAL is processed and all changes are propagated to indexes. After that the transaction is marked as completed and commit is finished. This behaviour is slowest but guarantees that the changes are persisted on disk and durable and that they are visible immediately after the commit is marked as completed.
The `COMPONENT_COMMIT_PIPELINE` component - the four version watermarks the commit pipeline maintains. A transaction is *assigned* a version at conflict resolution, *written* once it is in the write-ahead log, *durable* once that has been forced to disk, and *finalized* once it is visible to readers. The watermarks are always in that order, so the differences between them answer specific operational questions: assigned minus written is work accepted but not yet logged, written minus durable is how much replay a crash would cost right now, and written minus finalized is how far behind readers are.
Used in:
Newest catalog version handed out by conflict resolution.
Newest catalog version appended to the write-ahead log.
Newest catalog version forced to durable storage.
Newest catalog version visible to readers.
Outcome of computing one requested `GrpcCatalogStatisticsComponent`. Without it a client cannot tell a component it never requested from one the engine could not compute - both arrive as an absent sub-message - which is how a corrupted catalog ends up rendering as an empty one. A component is reported only if it was requested.
Used in:
Default value, never sent by the server. A status message always carries an explicit availability; receiving this means the message was default-constructed and must not be read as `AVAILABILITY_DELIVERED`.
The component was requested and computed - its sub-message is present in the response.
The catalog is corrupted and could not be loaded, and this component reads state that only a loaded catalog has. Components reading the file system directly - notably `COMPONENT_STORAGE_SIZE` - stay delivered even then.
The component depends on an engine feature switched off in the current configuration, for example time-travel history when write-ahead log retention is disabled. A configuration change makes it available.
Outcome of one requested `GrpcCatalogStatisticsComponent`, telling the client whether the matching sub-message of the snapshot is present because it was computed, or absent because it could not be. Only requested components get a status - a component the client did not ask for is absent from the status list entirely, which is what lets a client tell "I never asked for this" apart from "the server could not produce it".
Used in: ,
The component this status describes.
Whether the component was delivered, and if not, the machine-readable class of reason.
Human-readable explanation of why the component could not be delivered, meant to be shown to an operator. Unset when `availability` is `AVAILABILITY_DELIVERED`; never a substitute for reading `availability` itself.
Enum represents the coarse, mutually exclusive scope at which transaction conflicts are detected.
Used in:
No conflict detection is performed.
Conflicts are detected at the catalog level.
Conflicts are detected at the entity collection level.
Conflicts are detected at the entity level.
Represents the conflict resolution setting combining the coarse conflict policy scope with an optional set of sub-entity granular refinements. Used as an optional (nullable) field on catalog and entity schemas — an absent message means the schema inherits the resolved conflict resolution.
Used in: , , , , ,
The coarse, mutually exclusive scope at which conflicts are detected.
The set of sub-entity refinements; non-empty only when policy is set to entity level.
Enum represents the per-item override of the conflict resolution granularity applied to a schema element (attribute, associated data or reference).
Used in: , , , , , , , , , ,
The schema element follows the resolved conflict resolution (no explicit override).
Conflicts on this schema element are detected at granular (sub-entity) level.
Conflicts on this schema element are detected at whole-entity level.
Mutation is responsible for setting up a new `AssociatedDataSchema` in the `EntitySchema`. Mutation can be used for altering also the existing `AssociatedDataSchema` alone.
Used in:
Contains unique name of the model. Case-sensitive. Distinguishes one model item from another within single entity instance.
Contains description of the model is optional but helps authors of the schema / client API to better explain the original purpose of the model to the consumers.
Deprecation notice contains information about planned removal of this associated data from the model / client API. This allows to plan and evolve the schema allowing clients to adapt early to planned breaking changes.
Contains the data type of the entity. Must be one of supported types or may represent complex type - which is JSON object that can be automatically converted to the set of basic types.
Localized associated data has to be ALWAYS used in connection with specific `locale`. In other words - it cannot be stored unless associated locale is also provided.
When associated data is nullable, its values may be missing in the entities. Otherwise, the system will enforce non-null checks upon upserting of the entity.
The per-associated-data override of the conflict resolution granularity.
Mutation is responsible for setting up a new `AttributeSchema` in the `EntitySchema`. Mutation can be used for altering also the existing `AttributeSchema` alone.
Used in: ,
Name of the attribute the mutation is targeting.
Contains description of the model is optional but helps authors of the schema / client API to better explain the original purpose of the model to the consumers.
Deprecation notice contains information about planned removal of this attribute from the model / client API. This allows to plan and evolve the schema allowing clients to adapt early to planned breaking changes.
When attribute is unique it is automatically filterable, and it is ensured there is exactly one single entity having certain value of this attribute among other entities in the same collection. Deprecated since 2024.12 - deprecated in favor of `uniqueInScopes`
When attribute is filterable, it is possible to filter entities by this attribute. Do not mark attribute as filterable unless you know that you'll search entities by this attribute. Each filterable attribute occupies (memory/disk) space in the form of index. Deprecated since 2024.12 - deprecated in favor of `filterableInScopes`
When attribute is sortable, it is possible to sort entities by this attribute. Do not mark attribute as sortable unless you know that you'll sort entities along this attribute. Each sortable attribute occupies (memory/disk) space in the form of index. Deprecated since 2024.12 - deprecated in favor of `sortableInScopes`
Localized attribute has to be ALWAYS used in connection with specific `locale`. In other words - it cannot be stored unless associated locale is also provided.
When attribute is nullable, its values may be missing in the entities. Otherwise, the system will enforce non-null checks upon upserting of the entity.
If an attribute is flagged as representative, it should be used in developer tools along with the entity's primary key to describe the entity or reference to that entity. The flag is completely optional and doesn't affect the core functionality of the database in any way. However, if it's used correctly, it can be very helpful to developers in quickly finding their way around the data. There should be very few representative attributes in the entity type, and the unique ones are usually the best to choose.
Type of the attribute. Must be one of supported data types or its array.
Determines how many fractional places are important when entities are compared during filtering or sorting. It is significant to know that all values of this attribute will be converted to `Integer`, so the attribute number must not ever exceed maximum limits of `Integer` type when scaling the number by the power of ten using `indexedDecimalPlaces` as exponent.
Default value is used when the entity is created without this attribute specified. Default values allow to pass non-null checks even if no attributes of such name are specified.
When attribute is unique it is automatically filterable, and it is ensured there is exactly one single entity having certain value of this attribute among other entities in the same collection.
When attribute is filterable, it is possible to filter entities by this attribute. Do not mark attribute as filterable unless you know that you'll search entities by this attribute. Each filterable attribute occupies (memory/disk) space in the form of index.
When attribute is sortable, it is possible to sort entities by this attribute. Do not mark attribute as sortable unless you know that you'll sort entities along this attribute. Each sortable attribute occupies (memory/disk) space in the form of index.
The per-attribute override of the conflict resolution granularity.
The optional accelerations the attribute's filter index maintains, per scope. Only scopes the very same mutation gives the attribute a filter index in - i.e. makes it filterable or unique in - may appear here. An empty list - which is what an older client sends - means no acceleration anywhere.
Mutation is responsible for setting up a new CatalogSchema.
Used in:
Name of newly created catalog schema.
Optional catalog-level transaction conflict resolution override applied to the new catalog. When not set, the catalog inherits the engine-level default.
Mutation is responsible for setting up a new `EntitySchema` - or more precisely the collection within catalog.
Used in: ,
Name of newly created entity schema.
Mutation is responsible for setting up a new `GlobalAttributeSchema` in the `CatalogSchema`. Mutation can be used for altering also the existing `GlobalAttributeSchema` alone.
Used in:
Name of the attribute the mutation is targeting.
Contains description of the model is optional but helps authors of the schema / client API to better explain the original purpose of the model to the consumers.
Deprecation notice contains information about planned removal of this attribute from the model / client API. This allows to plan and evolve the schema allowing clients to adapt early to planned breaking changes.
When attribute is unique it is automatically filterable, and it is ensured there is exactly one single entity having certain value of this attribute among other entities in the same collection. Deprecated since 2024.12 - deprecated in favor of `uniqueInScopes`
When attribute is unique globally it is automatically filterable, and it is ensured there is exactly one single entity having certain value of this attribute in entire catalog. Deprecated since 2024.12 - deprecated in favor of `uniqueGloballyInScopes`
When attribute is filterable, it is possible to filter entities by this attribute. Do not mark attribute as filterable unless you know that you'll search entities by this attribute. Each filterable attribute occupies (memory/disk) space in the form of index. Deprecated since 2024.12 - deprecated in favor of `filterableInScopes`
When attribute is sortable, it is possible to sort entities by this attribute. Do not mark attribute as sortable unless you know that you'll sort entities along this attribute. Each sortable attribute occupies (memory/disk) space in the form of index. Deprecated since 2024.12 - deprecated in favor of `sortableInScopes`
Localized attribute has to be ALWAYS used in connection with specific `locale`. In other words - it cannot be stored unless associated locale is also provided.
When attribute is nullable, its values may be missing in the entities. Otherwise, the system will enforce non-null checks upon upserting of the entity.
If an attribute is flagged as representative, it should be used in developer tools along with the entity's primary key to describe the entity or reference to that entity. The flag is completely optional and doesn't affect the core functionality of the database in any way. However, if it's used correctly, it can be very helpful to developers in quickly finding their way around the data. There should be very few representative attributes in the entity type, and the unique ones are usually the best to choose.
Type of the attribute. Must be one of supported data types or its array.
Determines how many fractional places are important when entities are compared during filtering or sorting. It is significant to know that all values of this attribute will be converted to `Integer`, so the attribute number must not ever exceed maximum limits of `Integer` type when scaling the number by the power of ten using `indexedDecimalPlaces` as exponent.
Default value is used when the entity is created without this attribute specified. Default values allow to pass non-null checks even if no attributes of such name are specified.
When attribute is unique it is automatically filterable, and it is ensured there is exactly one single entity having certain value of this attribute among other entities in the same collection.
When attribute is unique globally it is automatically filterable, and it is ensured there is exactly one single entity having certain value of this attribute in entire catalog.
When attribute is filterable, it is possible to filter entities by this attribute. Do not mark attribute as filterable unless you know that you'll search entities by this attribute. Each filterable attribute occupies (memory/disk) space in the form of index.
When attribute is sortable, it is possible to sort entities by this attribute. Do not mark attribute as sortable unless you know that you'll sort entities along this attribute. Each sortable attribute occupies (memory/disk) space in the form of index.
The per-attribute override of the conflict resolution granularity.
The optional accelerations the attribute's filter index maintains, per scope. Only scopes the very same mutation gives the attribute a filter index in - i.e. makes it filterable or unique in - may appear here. An empty list - which is what an older client sends - means no acceleration anywhere.
Mutation is responsible for setting up a new `ReferenceSchema` in the `EntitySchema`. Mutation can be used for altering also the existing `ReferenceSchema` alone.
Used in:
Name of the reference the mutation is targeting.
Contains description of the model is optional but helps authors of the schema / client API to better explain the original purpose of the model to the consumers.
Deprecation notice contains information about planned removal of this schema from the model / client API. This allows to plan and evolve the schema allowing clients to adapt early to planned breaking changes.
Cardinality describes the expected count of relations of this type. In evitaDB we define only one-way relationship from the perspective of the entity. We stick to the ERD modelling [standards](https://www.gleek.io/blog/crows-foot-notation.html) here. Cardinality affect the design of the client API (returning only single reference or collections) and also help us to protect the consistency of the data so that conforms to the creator mental model.
Reference to `EntitySchema.name` of the referenced entity. Might be also any `String` that identifies type some external resource not maintained by Evita.
Whether `referencedEntityType` refers to any existing `EntitySchema.name` that is maintained by Evita.
Reference to `EntitySchema.name` of the referenced group entity. Might be also any `String` that identifies type some external resource not maintained by Evita.
Whether `referencedGroupType` refers to any existing `EntitySchema.name` that is maintained by Evita.
Whether the index for this reference should be created and maintained allowing to filter by `referenceHaving` filtering constraints. Index is also required when reference is `faceted`. Do not mark reference as faceted unless you know that you'll need to filter/sort entities by this reference. Each indexed reference occupies (memory/disk) space in the form of index. When reference is not indexed, the entity cannot be looked up by reference attributes or relation existence itself, but the data is loaded alongside other references if requested. Deprecated since 2024.12 - deprecated in favor of `indexedInScopes`
Whether the statistics data for this reference should be maintained and this allowing to get `referenceSummary` for this reference or use `facetInSet` filtering query. Do not mark reference as faceted unless you want it among `FacetStatistics`. Each faceted reference occupies (memory/disk) space in the form of index. Reference that was marked as faceted is called Facet. Deprecated since 2024.12 - deprecated in favor of `facetedInScopes`
Whether the index for this reference should be created and maintained allowing to filter by `referenceHaving` filtering constraints. Index is also required when reference is `faceted`. Do not mark reference as faceted unless you know that you'll need to filter/sort entities by this reference. Each indexed reference occupies (memory/disk) space in the form of index. When reference is not indexed, the entity cannot be looked up by reference attributes or relation existence itself, but the data is loaded alongside other references if requested. Deprecated since 2025.6 - deprecated in favor of `scopedIndexTypes`
Whether the statistics data for this reference should be maintained and this allowing to get `referenceSummary` for this reference or use `facetInSet` filtering query. Do not mark reference as faceted unless you want it among `FacetStatistics`. Each faceted reference occupies (memory/disk) space in the form of index. Reference that was marked as faceted is called Facet.
Scoped reference index types that define both the scope and the type of index for the reference. This replaces the deprecated `indexedInScopes` field with more granular control over indexing.
Scoped reference indexed components that specify which parts of a reference relationship (referenced entity, referenced group entity) are indexed per scope. When not specified, the default indexed components are determined automatically.
Per-scope expressions that narrow which entities participate in faceting.
Per-scope bucketed histogram configurations defining index name and value expression.
Per-scope expressions that narrow which entities participate in bucketed histogram computation.
The per-reference override of the conflict resolution granularity.
Mutation is responsible for setting up a new `ReflectedReferenceSchema` in the `EntitySchema`. Mutation can be used for altering also the existing `ReflectedReferenceSchema` alone.
Used in:
Name of the reference the mutation is targeting.
Contains description of the model is optional but helps authors of the schema / client API to better explain the original purpose of the model to the consumers.
Deprecation notice contains information about planned removal of this schema from the model / client API. This allows to plan and evolve the schema allowing clients to adapt early to planned breaking changes.
Cardinality describes the expected count of relations of this type. In evitaDB we define only one-way relationship from the perspective of the entity. We stick to the ERD modelling [standards](https://www.gleek.io/blog/crows-foot-notation.html) here. Cardinality affect the design of the client API (returning only single reference or collections) and also help us to protect the consistency of the data so that conforms to the creator mental model.
Reference to `EntitySchema.name` of the referenced entity. Might be also any `String` that identifies type some external resource not maintained by Evita.
Name of the reflected reference of the target referencedEntityType(). The referenced entity must contain reference of such name and this reference must target the entity where the reflected reference is defined, and the target entity must be managed on both sides of the relation.
Whether the statistics data for this reference should be maintained and this allowing to get `referenceSummary` for this reference or use `facetInSet` filtering query. Do not mark reference as faceted unless you want it among `FacetStatistics`. Each faceted reference occupies (memory/disk) space in the form of index. Reference that was marked as faceted is called Facet. Deprecated since 2024.12 - deprecated in favor of `facetedInScopes`
Contains true if the attributes of the reflected reference are inherited from the target reference.
The array of attribute names that are inherited / excluded from inheritance based on the value of attributeInheritanceBehavior property.
when set to true, the value of `indexedInScope` field is ignored and the settings are inherited from the original reference.
Whether the index for this reference should be created and maintained allowing to filter by `referenceHaving` filtering constraints. Index is also required when reference is `faceted`. Do not mark reference as faceted unless you know that you'll need to filter/sort entities by this reference. Each indexed reference occupies (memory/disk) space in the form of index. When reference is not indexed, the entity cannot be looked up by reference attributes or relation existence itself, but the data is loaded alongside other references if requested. Deprecated since 2025.6 - deprecated in favor of `scopedIndexTypes`
when set to true, the value of `facetedInScope` field is ignored and the settings are inherited from the original reference.
Whether the statistics data for this reference should be maintained and this allowing to get `referenceSummary` for this reference or use `facetInSet` filtering query. Do not mark reference as faceted unless you want it among `FacetStatistics`. Each faceted reference occupies (memory/disk) space in the form of index. Reference that was marked as faceted is called Facet.
Scoped reference index types that define both the scope and the type of index for the reference. This replaces the deprecated `indexedInScopes` field with more granular control over indexing. When `indexedInherited` is true, this field is ignored.
Scoped reference indexed components that specify which parts of a reference relationship (referenced entity, referenced group entity) are indexed per scope. When `indexedInherited` is true, this field is ignored.
Per-scope expressions that narrow which entities participate in faceting.
Per-scope bucketed histogram configurations defining index name and value expression.
Per-scope expressions that narrow which entities participate in bucketed histogram computation.
Mutation is responsible for setting up a new `SortableAttributeCompoundSchema` in the `EntitySchema`. Mutation can be used for altering also the existing `SortableAttributeCompoundSchema` alone.
Used in: ,
Name of the sortable attribute compound the mutation is targeting.
Contains description of the model is optional but helps authors of the schema / client API to better explain the original purpose of the model to the consumers.
Deprecation notice contains information about planned removal of this sortable attribute compound from the model / client API. This allows to plan and evolve the schema allowing clients to adapt early to planned breaking changes.
Defines list of individual elements forming this compound.
When attribute sortable compound is indexed, it is possible to sort entities by this calculated attribute compound. This property contains set of all scopes this attribute compound is indexed in.
Structure for representing Currency objects specified by currency code.
Used in: , , , , , , , ,
ISO 4217 three-letter currency code (e.g. `USD`, `EUR`), resolved via `Currency#getInstance(String)`.
Wrapper for representing an array of Currencies.
Used in: ,
The individual Currency elements, in their original order.
A page or strip of entities, in one of three representations (references, full sealed entities, or binary entities) depending on what the query's `require` block asked for. Only one representation is populated per response and only one of the two pagination descriptors below is set, matching whichever paging requirement (`page()`/`strip()`) the query used.
Used in:
Entity references (type + primary key only, no content). Populated when the query's `require` block has no `entityFetch` requirement; `sealedEntities`/`binaryEntities` are then both empty.
Fully fetched entities in structured (non-binary) form. Populated when `require` has an `entityFetch` requirement and the session is not using the binary storage format; `entityReferences`/`binaryEntities` are then both empty.
Fully fetched entities in the server's binary storage format, for clients that decode entities themselves. Populated when `require` has an `entityFetch` requirement and the session uses the binary storage format; `entityReferences`/`sealedEntities` are then both empty.
Exactly one of these is set, matching which paging requirement (`page()`/`strip()`) the query used.
Set when the query used page-based paging (`page()`).
Set when the query used strip/offset-based paging (`strip()`).
Total number of records matching the query across all pages/strips, not just this chunk's size.
True if this chunk is the first page/strip of the result set.
True if this chunk is the last page/strip of the result set.
True if a preceding page/strip exists.
True if a following page/strip exists.
True if the entire result set fits within this single chunk.
True if this chunk (and the entire result set) contains no records.
Structure that holds one node of a complex (structured) associated data value's recursive tree. A node is either a leaf primitive value, an array of child nodes, or a map of named child nodes.
Used in: , ,
Exactly one of these is set, identifying which kind of node this is.
Leaf node: the primitive value at this position of the tree (evitaDB `DataItemValue`).
Array node: the ordered child nodes at this position of the tree (evitaDB `DataItemArray`).
Map node: the named child nodes at this position of the tree (evitaDB `DataItemMap`).
Structure that holds an array-typed node of a complex associated data value's tree.
Used in:
The ordered child nodes of this array node, in their original order.
The `COMPONENT_FRAGMENTATION` component for ONE data store - how much of it is still live, how fast that is getting worse, and whether it already satisfies the compaction predicate. One message serves every place a data store is described, because they are the same measurements of the same kind of thing: one entity collection's data store (`GrpcEntityCollectionStatisticsSnapshot.fragmentation`), and the catalog's own data store holding the catalog schema, the catalog and collection headers and the catalog-level indexes (`GrpcFragmentationStatistics.catalogDataStore`). The catalog-wide figures on `GrpcFragmentationStatistics` are the fold of all of them. The configured thresholds the predicate is evaluated against are catalog-wide and are reported once, on `GrpcFragmentationStatistics`, rather than repeated for every store. `activeRecordShare` is derived from the two byte figures reported with it and is NOT the share the predicate is evaluated against - that one is measured against the file length, which also carries the serialized offset-index table. The verdict is `compactionEligibleNow`, never a comparison of this share to a threshold.
Used in: ,
`liveBytes / (liveBytes + wasteBytes)` for this data store, in the range 0..1; `1.0` when nothing is stored in it yet.
Active records in it (bytes).
Bytes compacting it would reclaim (bytes).
True when this data store already satisfies the compaction predicate.
Bytes stranded by rewrites and removals since this data store was opened or last compacted (bytes).
Rate at which `wasteBytesGenerated` grows, smoothed over recent flushes and decayed while nothing is being written; `0` when no waste is accruing (bytes per second).
Projected time at which this data store crosses the predicate. Unset when no crossing follows from the current rate, and unset once `compactionEligibleNow` holds - a store that is already due needs no forecast.
The collection-level `COMPONENT_VOLATILE_STATE` component - what one collection's data store holds in memory but not yet on disk, and what it keeps alive purely for readers that started long ago.
Used in: ,
Size this data store occupies including data not yet flushed (bytes).
Records written but not yet flushed (records).
Size those records occupy (bytes).
Creation time of the oldest record kept for an open session. Unset when nothing is being retained.
Representation of DateTimeRange structures. At least one of `from`/`to` should be set; if both are absent, the range decodes to a degenerate range anchored at the Unix epoch (1970-01-01T00:00:00Z) rather than being unbounded in both directions.
Used in: , , , , ,
The inclusive lower bound (start) of the range. If unset (while `to` is set), the range is unbounded below (open start).
The inclusive upper bound (end) of the range. If unset (while `from` is set), the range is unbounded above (open end).
Wrapper for representing an array of DateTimeRanges.
Used in: ,
The individual DateTimeRange elements, in their original order.
Request to deactivate a catalog.
Used as request type in: EvitaService.DeactivateCatalog, EvitaService.DeactivateCatalogWithProgress
Name of the catalog to deactivate.
Request for deleting a single entity by primary key and returning it fetched in the richness described by `require` before deletion.
Used as request type in: EvitaSessionService.DeleteEntity, EvitaSessionService.DeleteEntityAndItsHierarchy
Entity type (collection name) the entity to delete belongs to.
Primary key of the entity to delete. Effectively mandatory despite the wrapper type: the server reads its value directly without checking presence, so an unset value is treated identically to an explicit `0` rather than as "no primary key" - always set this field explicitly.
The string part of a parametrised `require` query fragment describing how richly to fetch the entity back before it is deleted. `?`/`@name` placeholders are bound the same way as `positionalQueryParams`/`namedQueryParams` on `GrpcEntityRequest` - see there for the full binding contract.
Values for the `?` positional placeholders in `require`, bound in encounter order (FIFO) - see `GrpcEntityRequest.positionalQueryParams` for the full binding contract.
Values for the `@name` named placeholders in `require`, keyed by name (without the `@` prefix) - see `GrpcEntityRequest.namedQueryParams` for the full binding contract.
Mutation is responsible for removing one or more currencies from a `EntitySchema.currencies` in `EntitySchema`.
Used in:
Set of all currencies that can't be used for prices in entities of this type.
Mutation is responsible for removing one or more modes from a `CatalogSchema.evolutionMode` in `CatalogSchema`.
Used in:
Set of forbidden evolution modes. These allow to specify how strict is evitaDB when unknown information is presented to her for the first time. When no evolution mode is set, each violation of the `CatalogSchema` is reported by an error. This behaviour can be changed by this evolution mode, however.
Mutation is responsible for removing one or more modes from a `EntitySchema.evolutionMode` in `EntitySchema`.
Used in:
Set of forbidden evolution modes. These allow to specify how strict is evitaDB when unknown information is presented to her for the first time. When no evolution mode is set, each violation of the `EntitySchema` is reported by an error. This behaviour can be changed by this evolution mode, however.
Mutation is responsible for removing one or more locales from a `EntitySchema.locales` in `EntitySchema`.
Used in:
Set of all locales that can't be used for localized `AttributeSchema` or `AssociatedDataSchema`.
Mutation that duplicates a catalog with a new name, copying all contents from the source catalog.
Used in:
Name of the source catalog to duplicate.
Name of the new catalog to create with duplicated contents.
Request to duplicate a catalog.
Used as request type in: EvitaService.DuplicateCatalog, EvitaService.DuplicateCatalogWithProgress
Name of the source catalog to duplicate.
Name of the new catalog to create with duplicated contents.
The catalog-level `COMPONENT_DURABILITY` component - how far behind the physical device this catalog is allowed to run, and what the last checkpoint to catch it up cost. A checkpoint forces the writes made since the previous one to the device and writes the bootstrap record pointing at them, no more often than the configured interval. Between checkpoints the catalog is crash-consistent but behind: a crash replays the write-ahead log from the last checkpoint forward, and that window is what this component measures. This is the time-domain answer to "how much replay would a crash cost me right now". `GrpcCommitPipelineStatistics` answers the same question in catalog versions, and neither derives from the other - a handful of large transactions and a flood of small ones give the same version lag and very different fence depths. A catalog that checkpoints at the end of every round reports `AVAILABILITY_FEATURE_DISABLED` instead of this message, rather than reporting a fence of depth zero.
Used in:
The configured interval a checkpoint is deferred by (milliseconds). The upper bound on how long a change may wait to become durable, and therefore the knob trading write throughput against crash-replay cost.
Time between the last two completed checkpoints (milliseconds); `0` before the first one completes, and measured from the catalog's open for the first one. A value above `checkpointIntervalMillis` is NOT a problem signal on its own - it is the normal reading for a catalog that is written to rarely, where every round checkpoints inline and the fence depth stays `0`. Alone this figure cannot tell an idle catalog from an overloaded one; alert on `lastFenceDepthMillis` exceeding `checkpointIntervalMillis` instead, and read this one alongside it.
How long the oldest change covered by the last checkpoint waited to become durable (milliseconds); `0` when that round checkpointed without deferring anything. Measured from the end of the first round that deferred, so it is a lower bound on the age of the oldest change a crash at that moment would have replayed - NOT the duration of the device force, which is `lastForceDurationMillis`. Never greater than `lastCadenceMillis`; the difference between the two is time in which nothing was owed to the device.
Number of files the last checkpoint forced to the device.
Wall-clock time those forces took (milliseconds) - the cost the checkpoint interval exists to amortise, paid once per checkpoint instead of once per round.
Checkpoints completed since `countingSince`.
When the last checkpoint completed. If unset, no checkpoint has completed since this catalog was opened - a freshly opened or write-idle catalog, not a stalled one. `lastCadenceMillis` reads `0` in the same situation; tell the two apart using the write rate in `GrpcActivityStatistics`.
The instant `checkpointsCompleted` was zeroed. The counter is process-scoped and is not persisted, so it starts at zero when the catalog is opened; without this instant it cannot be read as a rate or compared across polls.
The enumeration controls HierarchyOfReference behaviour whether the hierarchical nodes that are not referred by any of the queried entities should be part of the result hierarchy statistics tree.
Used in: ,
The hierarchy nodes that are not referred by any of the queried entities will be part of the result hierarchy
The hierarchy nodes that are not referred by any of the queried entities will be removed from the result hierarchy
Wrapper for representing an array of EmptyHierarchicalEntityBehaviour enums.
Used in:
The individual EmptyHierarchicalEntityBehaviour values, in their original order.
A named endpoint exposed by an external API, distinct from the API's own base URL(s) (see `GrpcApiStatus.endpoints`).
Used in:
Logical name identifying what the endpoint serves. For the system API - currently the only API that populates `GrpcApiStatus.endpoints` - this is one of `serverNameUrl`, `serverCertificateUrl`, `clientCertificateUrl`, `clientPrivateKeyUrl`.
Absolute URL(s) the endpoint is reachable on - one per configured host binding, so this commonly holds more than one URL even though the field name is singular.
This structure encapsulates all mutations that needs to be executed on entire evitaDB level and not locally to single catalog schema instance.
Used in: ,
The top level catalog schema mutation to be executed.
Mutation is responsible for setting up a new CatalogSchema.
Mutation is responsible for renaming an existing CatalogSchema.
Mutation is responsible for renaming an existing CatalogSchema.
Mutation that transitions a catalog to the "live" state, making it transactional.
Mutation is responsible for removing an existing CatalogSchema.
Mutation delimits one transaction from another.
Mutation that sets the mutability state of a catalog.
Mutation that duplicates a catalog with a new name, copying all contents from the source catalog.
Mutation that sets the active state of a catalog.
Mutation is responsible for restoring a CatalogSchema in INACTIVE state.
Mutation that records the fact a catalog's on-disk folder is no longer present.
Mutation that upgrades a catalog's on-disk storage protocol to the engine's current version.
Structure that holds changes in a specific entity collection within a transaction.
Used in:
The name (entity type) of the entity collection these counts apply to.
The number of schema altering mutations.
The number of upsert entity mutations.
The number of entity removal mutations.
Aggregates basic data about the entity collection.
Used in:
name of the entity collection
total number of records in the entity collection
total number of indexes in the entity collection
total size of the entity collection on disk in bytes
A component-selected snapshot of exactly one entity collection's statistics. A separate message from the catalog-level snapshot rather than a row nested inside it: the catalog snapshot is the one that gets polled, and nesting a row per collection would make its size grow with the number of collections and would let the expensive per-collection components leak into a request that must stay cheap. Presence rules are the same as at the catalog level - `identity` and `entityType` are always set, and every other field is present only when its component was requested and delivered. Requesting a catalog-only component here is an error, and so is naming a collection the catalog does not hold. One rule is *stronger* here than at the catalog level: a collection-level component cannot be declined. Every component this server delivers reports `AVAILABILITY_DELIVERED`, so a requested component's field is always set. A catalog can be warming up, corrupted, or configured with a feature switched off and still owe the caller an answer; a collection of a catalog in any of those states cannot be reached to be asked at all. Clients should nonetheless keep reading `componentStatus` rather than assuming presence - it is what stays correct against a server that declines one.
Used in:
The catalog this collection belongs to, and the version this snapshot was taken at; always present.
Name of the entity collection this snapshot describes; always present.
The `COMPONENT_COLLECTIONS` component, i.e. this collection's header counters; absent unless requested and delivered.
The `COMPONENT_RECORD_COUNTS` component; absent unless requested and delivered.
The `COMPONENT_STORAGE_SIZE` component; absent unless requested and delivered.
The `COMPONENT_STORAGE_COMPOSITION` component; absent unless requested and delivered.
The `COMPONENT_FRAGMENTATION` component; absent unless requested and delivered.
The `COMPONENT_INDEX_SUMMARY` component; absent unless requested and delivered.
The `COMPONENT_VOLATILE_STATE` component; absent unless requested and delivered.
The `COMPONENT_INDEX_CARDINALITY` component; absent unless requested and delivered. Expensive to produce and never part of a polled refresh - request it only when a developer opened this collection.
Outcome of every requested component, `COMPONENT_IDENTITY` included. Components that were not requested have no entry here at all.
Contains set of all possible expected states for the entity.
Used in:
Entity may or may not exist.
Entity must not exist.
Entity must exist.
Type of entity index, as reported by the per-collection index summary and by an index browse. This is the engine's own index type vocabulary rather than a mirror of it, so the values cannot drift apart. A catalog index has no value here: the engine addresses those by scope alone because there is exactly one kind of them.
Used in: , , ,
Default value, never sent by the server. Every reported index carries an explicit type.
Index covering all entities of the collection.
Index covering entities that reference any entity of a particular referenced entity type.
Index covering entities that reference one particular referenced entity.
Index covering entities that reference any entity belonging to a particular group entity type.
Index covering entities that reference one particular group entity.
Represents a mutation to be performed on the evitaDB that relates to an entity.
Used as request type in: EvitaSessionService.ApplyMutation
Used as field type in: , ,
The mutation to be performed.
Represents a terminal mutation that wraps a list of mutation that are to be performed on an entity.
Represents a terminal mutation when existing entity is removed in the evitaDB. The entity with all its internal data are deleted.
This type represents a reference to any Evita entity and that is returned by default for all queries that don't require loading additional data.
Used in: , , , , , , , , , , , ,
Type of entity. Entity type is main sharding key - all data of entities with same type are stored in separated collections. Within the entity type entity is uniquely represented by primary key.
Unique Integer positive number representing the entity. Can be used for fast lookup for entity (entities). Primary key must be unique within the same entity type.
Deprecated since 2024.10 - value is deprecated, it was available only for entity references used in entity body, in other use-cases it was left as zero - which was a mistake in the design. in order to get the entity version you need to fetch the entity itself (with entity body).
Contains version of this reference and gets increased with any entity type update. Allows to execute optimistic locking i.e. avoiding parallel modifications.
Extended entity reference that maintains a mapping of reassigned primary keys for entity references. This type is used during entity mutations when references need to be tracked with their newly assigned internal primary keys after persistence. When references are first created, they are assigned temporary negative internal primary keys. Upon persistence to the database, these temporary keys are replaced with positive permanent internal primary keys assigned by the server. This message maintains the mapping between the original reference keys (with temporary internal PKs) and the reference keys with their newly assigned permanent internal PKs. This is particularly useful when: - Multiple references share the same business key but differ in properties - Client code needs to track which references were assigned which internal primary keys after persistence - References need to be looked up by their original temporary keys to find their permanent counterparts
Used in:
Type of entity. Entity type is main sharding key - all data of entities with same type are stored in separated collections. Within the entity type entity is uniquely represented by primary key.
Unique Integer positive number representing the entity. Can be used for fast lookup for entity (entities). Primary key must be unique within the same entity type.
Mapping from original reference keys (with temporary internal PK) to the new reference keys with permanent internal PK assigned by the server after persistence. The map key is the original reference key, and the value is the reassigned reference key.
Entity reference which contains information about parent entity.
Used in:
Type of entity. Entity type is main sharding key - all data of entities with same type are stored in separated collections. Within the entity type entity is uniquely represented by primary key.
Unique Integer positive number representing the entity. Can be used for fast lookup for entity (entities). Primary key must be unique within the same entity type.
Contains version of this entity and gets increased with any entity type update. Allows to execute optimistic locking i.e. avoiding parallel modifications. Deprecated since 2024.10 - value is deprecated, it was never available in the first place - it was a mistake in the design. in order to get the entity version you need to fetch the entity itself (with entity body).
Recursive pointer to parent entity. When the ancestor above this one carries a requested body, this field still holds that ancestor - reduced to its primary key and its own chain of primary keys - so that a client which does not know `parentEntity` still receives the complete chain of ancestor primary keys, only without their bodies. Unset means nothing is reported above this ancestor: it is a hierarchy root, or the chain was cut by a `stopAt` bound or by the `MATCHING` parents behaviour.
The very same ancestor as `parent`, carrying the body that was requested for it. Set only under the `COMPLETE` parents behaviour, which keeps an ancestor whose requested body could not be materialized in the chain as a bodyless pointer and continues the walk above it - so an ancestor carrying a body may sit above one that does not. Unset means the ancestor above this one has no body to report, either because none was requested, because it could not be materialized, or because there is no ancestor at all; read `parent` in that case. When both are set they describe one and the same ancestor, and `parentEntity` is the richer of the two.
Represents a terminal mutation when existing entity is removed in the evitaDB. The entity is and all its internal data are deleted.
Used in:
The type of the entity to be removed.
The primary key of the entity to be removed.
This is the definition object for entity. Definition objects allow to describe the structure of the entity type so that in any time everyone can consult complete structure of the entity type. Based on our experience we've designed following data model for handling entities in evitaDB. Model is rather complex but was designed to limit amount of data fetched from database and minimize an amount of data that are indexed and subject to search. Minimal entity definition consists of: - entity type and - primary key (even this is optional and may be autogenerated by the database). Other entity data is purely optional and may not be used at all.
Used in: , ,
Contains unique name of the model. Case-sensitive. Distinguishes one model item from another within single entity instance.
Contains version of this entity schema and gets increased with any entity type update. Allows to execute optimistic locking i.e. avoiding parallel modifications.
Contains description of the model is optional but helps authors of the schema / client API to better explain the original purpose of the model to the consumers.
Deprecation notice contains information about planned removal of this entity from the model / client API. This allows to plan and evolve the schema allowing clients to adapt early to planned breaking changes. If notice is `null`, this schema is considered not deprecated.
Contains `true` when primary keys of entities of this type will not be provided by the external systems and Evita is responsible for generating unique primary keys for the entity on insertion. Generated key is guaranteed to be unique, but may not represent continuous ascending series. Generated key will be always greater than zero.
Contains `true` when entities of this type are organized in a tree like structure (hierarchy) where certain entities are subordinate of other entities. Entities may be organized in hierarchical fashion. That means that entity may refer to single parent entity and may be referred by multiple child entities. Hierarchy is always composed of entities of same type. Each entity must be part of at most single hierarchy (tree). Hierarchy can limit returned entities by using filtering constraints. It's also used for computation of extra data - such as the `parents` requirement. It can also invert type of returned entities in case extra result `hierarchyOfSelf` is requested.
Contains `true` when entities of this type holds price information. Prices are specific to a very few entities, but because correct price computation is very complex in e-commerce systems and highly affects performance of the entities filtering and sorting, they deserve first class support in entity model. It is pretty common in B2B systems single product has assigned dozens of prices for the different customers. Specifying prices on entity allows usage of `priceValidIn`, `priceInCurrency` `priceBetween`, and `priceInPriceLists` filtering constraints and also `priceNatural`, ordering of the entities. Additional extra result `priceHistogram` and requirement `priceType` can be used in query as well.
Determines how many fractional places are important when entities are compared during filtering or sorting. It is important to know that all prices will be converted to `Int`, so any of the price values (either with or without tax) must not ever exceed maximum limits of `Int` type when scaling the number by the power of ten using `indexedPricePlaces` as exponent.
Contains set of all `Locale` that could be used for localized `AttributeSchema` or `AssociatedDataSchema`. Enables using `entityLocaleEquals` filtering constraint in query.
Contains set of all `Currency` that could be used for `prices` in entities of this type.
Contains index of all `AttributeSchema` that could be used as attributes of entity of this type. Entity (global) attributes allows defining set of data that are fetched in bulk along with the entity body. Attributes may be indexed for fast filtering (`AttributeSchema.filterable`) or can be used to sort along (`AttributeSchema.sortable`). Attributes are not automatically indexed in order not to waste precious memory space for data that will never be used in search queries. Filtering in attributes is executed by using constraints like `and`, `not`, `attributeEquals`, `attributeContains` and many others. Sorting can be achieved with `attributeNatural` or others. Attributes are not recommended for bigger data as they are all loaded at once requested. Large data that are occasionally used store in `associatedData`.
Contains index of all `AssociatedDataSchema` that could be used as associated data of entity of this type. Associated data carry additional data entries that are never used for filtering / sorting but may be needed to be fetched along with entity in order to present data to the target consumer (i.e. user / API / bot). Associated data may be stored in slower storage and may contain wide range of data types - from small ones (i.e. numbers, strings, dates) up to large binary arrays representing entire files (i.e. pictures, documents). The search query must contain specific associated data fields in order associated data are fetched along with the entity. Associated data are stored and fetched separately by their name.
Contains index of all `ReferenceSchema` that could be used as references of entity of this type. References refer to other entities (of same or different entity type). Allows entity filtering (but not sorting) of the entities by using `facetInSet` constraint and statistics computation when `facetStatistics` extra result is requested. Reference is uniquely represented by int positive number (max. (2^63)-1) and entity type and can be part of multiple reference groups, that are also represented by int and entity type. Reference id in one entity is unique and belongs to single reference group id. Among multiple entities reference may be part of different reference groups. Referenced entity type may represent type of another Evita entity or may refer to anything unknown to Evita that posses unique int key and is maintained by external systems (fe. tag assignment, group assignment, category assignment, stock assignment and so on). Not all these data needs to be present in Evita. References may carry additional key-value data linked to this entity relation (fe. item count present on certain stock). The search query must contain specific `referenceContent` requirement in order references are fetched along with the entity.
Evolution mode allows to specify how strict is evitaDB when unknown information is presented to her for the first time. When no evolution mode is set, each violation of the `EntitySchema` is reported by an exception. This behaviour can be changed by this evolution mode however.
Contains index of definitions of all sortable attribute compounds defined in this schema.
Contains entity type converted to different naming conventions.
Contains set of all scopes the entity is indexed in and can be used for filtering entities and computation of extra data. If the hierarchy information is not indexed, it is still available on the entity itself (i.e. entity can define its parent entity), but it is not possible to work with the hierarchy information in any other way (calculating parent chain, children, siblings, etc.).
Contains set of all scopes the price information is indexed in and can be used for filtering entities and computation of extra data. If the price information is not indexed, it is still available on the entity itself (i.e. entity can define its price), but it is not possible to work with the price information in any other way (calculating price histogram, filtering, sorting by price, etc.). Prices can be also set as non-indexed individually via the individual price's own `indexed` flag.
Contains current version of the catalog schema this entity schema belongs to.
Contains the entity-level conflict resolution setting. When not set (absent), the entity schema inherits the resolved conflict resolution from the catalog / transaction options.
Contains all possible entity schema mutations.
Used in: , ,
The mutation to be executed.
Mutation is responsible for setting up a new `AssociatedDataSchema` in the `EntitySchema`. Mutation can be used for altering also the existing `AssociatedDataSchema` alone.
Mutation is responsible for setting value to a `AssociatedDataSchemaContract.deprecationNotice` in `EntitySchema`. Mutation can be used for altering also the existing `AssociatedDataSchema` alone.
Mutation is responsible for setting value to a `AssociatedDataSchema.description` in `EntitySchema`. Mutation can be used for altering also the existing `AssociatedDataSchema` alone.
Mutation is responsible for renaming an existing `AssociatedDataSchema` in `EntitySchema`. Mutation can be used for altering also the existing `AssociatedDataSchema` alone.
Mutation is responsible for setting value to a `AssociatedDataSchema.type` in `EntitySchema`. Mutation can be used for altering also the existing `AssociatedDataSchema` alone.
Mutation is responsible for removing an existing `AssociatedDataSchema` in the `EntitySchema`. Mutation can be used for altering also the existing `AssociatedDataSchema` alone.
Mutation is responsible for setting value to a `AssociatedDataSchema.localized` in `EntitySchema`. Mutation can be used for altering also the existing `AssociatedDataSchema` alone.
Mutation is responsible for setting value to a `AssociatedDataSchema.nullable` in `EntitySchema`. Mutation can be used for altering also the existing `AssociatedDataSchema` alone.
Mutation is responsible for setting value to a `AssociatedDataSchema.conflictResolutionOverride` in `EntitySchema`. Mutation can be used for altering also the existing `AssociatedDataSchema` alone.
Mutation is responsible for setting up a new `AttributeSchema` in the `EntitySchema`. Mutation can be used for altering also the existing `AttributeSchema` alone.
Mutation is responsible for setting value to a `AttributeSchema.defaultValue` in `EntitySchema`. Mutation can be used for altering also the existing `AttributeSchema` or `GlobalAttributeSchema` alone.
Mutation is responsible for setting value to a `AttributeSchema.deprecationNotice` in `EntitySchema`. Mutation can be used for altering also the existing `AttributeSchema` or `GlobalAttributeSchema` alone.
Mutation is responsible for setting value to a `AttributeSchema.description` in `EntitySchema`. Mutation can be used for altering also the existing `AttributeSchema` or `GlobalAttributeSchema` alone.
Mutation is responsible for renaming an existing `AttributeSchema` in `EntitySchema` or `GlobalAttributeSchema` in `CatalogSchema`. Mutation can be used for altering also the existing `AttributeSchema` or `GlobalAttributeSchema` alone.
Mutation is responsible for setting value to a `AttributeSchema.type` in `EntitySchema`. Mutation can be used for altering also the existing `AttributeSchema` or `GlobalAttributeSchema` alone.
Mutation is responsible for removing an existing `AttributeSchema` in the `EntitySchema` or `GlobalAttributeSchema` in the `CatalogSchema`. Mutation can be used for altering also the existing `AttributeSchema` or `GlobalAttributeSchema` alone.
Mutation is responsible for setting value to a `AttributeSchema.filterable` in `EntitySchema`. Mutation can be used for altering also the existing `AttributeSchema` or `GlobalAttributeSchema` alone.
Mutation is responsible for setting value to a `AttributeSchema.localized` in `EntitySchema`. Mutation can be used for altering also the existing `AttributeSchema` or `GlobalAttributeSchema` alone.
Mutation is responsible for setting value to a `AttributeSchema.nullable` in `EntitySchema`. Mutation can be used for altering also the existing `AttributeSchema` or `GlobalAttributeSchema` alone.
Mutation is responsible for setting value to a `AttributeSchema.representative` in `EntitySchema`. Mutation can be used for altering also the existing `AttributeSchema` or `GlobalAttributeSchema` alone.
Mutation is responsible for setting value to a `AttributeSchema.sortable` in `EntitySchema`. Mutation can be used for altering also the existing `AttributeSchema` or `GlobalAttributeSchema` alone.
Mutation is responsible for setting value to a `AttributeSchema.unique` in `EntitySchema`. Mutation can be used for altering also the existing `AttributeSchema` or `GlobalAttributeSchema` alone.
Mutation is responsible for introducing a `GlobalAttributeSchema` into an `EvitaSession`.
Mutation is responsible for setting value `AttributeSchema.conflictResolutionOverride` in `EntitySchema`.
Mutation is responsible for setting the filter accelerators of an `AttributeSchema` in `EntitySchema`. Mutation can be used for altering also the existing `AttributeSchema` or `GlobalAttributeSchema` alone.
Mutation is responsible for adding one or more currencies to a `EntitySchema.currencies` in `EntitySchema`.
Mutation is responsible for adding one or more modes to a `EntitySchema.evolutionMode` in `EntitySchema`.
Mutation is responsible for adding one or more locales to a `EntitySchema.locales` in `EntitySchema`.
Mutation is responsible for removing one or more currencies from a `EntitySchema.currencies` in `EntitySchema`.
Mutation is responsible for removing one or more modes from a `EntitySchema.evolutionMode` in `EntitySchema`.
Mutation is responsible for removing one or more locales to a `EntitySchema.locales` in `EntitySchema`.
Mutation is responsible for setting a `EntitySchema.deprecationNotice` in `EntitySchema`.
Mutation is responsible for setting a `EntitySchema.description` in `EntitySchema`.
Mutation is responsible for setting a `EntitySchema.withGeneratedPrimaryKey` in `EntitySchema`.
Mutation is responsible for setting a `EntitySchema.withHierarchy` in `EntitySchema`.
Mutation is responsible for setting a `EntitySchema.withPrice` in `EntitySchema`.
Mutation is responsible for renaming or replacing a `EntitySchema`.
Mutation is responsible for removing a `EntitySchema` - i.e. entity collection.
Mutation is responsible for setting up a new `EntitySchema` in the `CatalogSchema`.
Mutation is responsible for modifying existing `EntitySchema` in the `CatalogSchema`.
Mutation is responsible for setting value to a `EntitySchema.conflictResolution` in `EntitySchema`.
Mutation is responsible for setting up a new `ReferenceSchema` in the `EntitySchema`. Mutation can be used for altering also the existing `ReferenceSchema` alone.
Mutation is a holder for a single `AttributeSchema` that affect any of `ReferenceSchema.attributes` in the `EntitySchema`.
Mutation is responsible for setting value to a `ReferenceSchema.cardinality` in `EntitySchema`.
Mutation is responsible for setting value to a `ReferenceSchema.deprecationNotice` in `EntitySchema`.
Mutation is responsible for setting value to a `ReferenceSchema.description` in `EntitySchema`. Mutation can be used for altering also the existing `ReferenceSchema` alone.
Mutation is responsible for renaming an existing `ReferenceSchema` in `EntitySchema`. Mutation can be used for altering also the existing `ReferenceSchema` alone.
Mutation is responsible for setting value to a `ReferenceSchema.referencedGroupType` in `EntitySchema`.
Mutation is responsible for setting value to a `ReferenceSchema.referencedEntityType` in `EntitySchema`. Mutation can be used for altering also the existing `ReferenceSchema` alone.
Mutation is responsible for removing an existing `ReferenceSchema` in the `EntitySchema`. Mutation can be used for altering also the existing `ReferenceSchema` alone.
Mutation is responsible for setting value to a `ReferenceSchema.faceted` in `EntitySchema`. Mutation can be used for altering also the existing `ReferenceSchema` alone.
Mutation is responsible for setting value to a `ReferenceSchema.indexed` in `EntitySchema`. Mutation can be used for altering also the existing `ReferenceSchema` alone.
Mutation is responsible for setting up a new `ReflectedReferenceSchema` in the `EntitySchema`. Mutation can be used for altering also the existing `ReflectedReferenceSchema` alone.
Mutation is responsible for setting value to a `ReflectedReferenceSchema.attributesInherited` and `ReflectedReferenceSchema.attributesExcludedFromInheritance` in `ReferenceSchema`. Mutation can be used for altering also the existing `ReferenceSchemaContract` alone.
Mutation is a holder for a single `SortableAttributeCompoundSchema` that affect any of `ReferenceSchema.sortableAttributeCompound` in the `EntitySchema`.
Mutation is responsible for setting bucketed histogram configuration on a `ReferenceSchema` in `EntitySchema`. Mutation can be used for altering also the existing `ReferenceSchema` alone.
Mutation is responsible for setting value to a `ReferenceSchema.conflictResolutionOverride` in `EntitySchema`. Mutation can be used for altering also the existing `ReferenceSchema` alone.
Mutation is responsible for setting up a new `SortableAttributeCompoundSchema` in the `EntitySchema`. Mutation can be used for altering also the existing `SortableAttributeCompoundSchema` alone.
Mutation is responsible for setting value to a `SortableAttributeCompoundSchema.deprecationNotice` in `EntitySchema` or `ReferenceSchema`.
Mutation is responsible for setting value to a `SortableAttributeCompoundSchema.description` in `EntitySchema` or `ReferenceSchema`.
Mutation is responsible for renaming an existing `SortableAttributeCompoundSchema` in `EntitySchema` or `ReferenceSchema`.
Mutation is responsible for removing an existing `SortableAttributeCompound` in the `EntitySchema` or `ReferenceSchema`.
Mutation is responsible for setting set of scopes for indexing value in a `SortableAttributeCompoundSchema` in `EntitySchema`.
Enum defines the possible scopes where the entities can reside.
Used in: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,
Entities that are currently active and reside in the live data set block.
Entities that are no longer active and reside in the archive block.
Wrapper for representing an array of Scope enums.
Used in:
The individual Scope values, in their original order.
Represents a terminal mutation that wraps a list of mutation that are to be performed on an entity.
Used in:
The type of the entity to be mutated.
The primary key of the entity to be mutated.
Controls behaviour of the upsert operation. - MUST_NOT_EXIST: use when you know you'll be inserting a new value - MUST_EXIST: use when you know you'll be updating an existing value - MAY_EXIST: use when you're not sure
List of all local mutations that modify internal data of the entity.
This enum contains all supported data types of AssociatedData.
(message has no fields)
Enumerates the value types evitaDB supports for associated data (both scalar and array variants) - a subset of the general query data types plus `ComplexDataObject` for arbitrary nested structures.
Used in: , , ,
Represents string data type.
Represents byte data type.
Represents short data type.
Represents integer data type.
Represents long data type.
Represents boolean data type.
Represents character data type.
Represents BigDecimal data type.
Represents OffsetDateTime data type.
Represents LocalDateTime data type.
Represents LocalDate data type.
Represents LocalTime data type.
Represents DateTimeRange data type.
Represents BigDecimalNumberRange data type.
Represents LongNumberRange data type.
Represents IntegerNumberRange data type.
Represents ShortNumberRange data type.
Represents ByteNumberRange data type.
Represents Locale data type.
Represents Currency data type.
Represents UUID data type.
Represents ComplexDataObject data type.
Represents string array data type.
Represents byte array data type.
Represents short array data type.
Represents integer array data type.
Represents long array data type.
Represents boolean array data type.
Represents character array data type.
Represents BigDecimal array data type.
Represents OffsetDateTime array data type.
Represents LocalDateTime array data type.
Represents LocalDate array data type.
Represents LocalTime array data type.
Represents DateTimeRange array data type.
Represents BigDecimalNumberRange array data type.
Represents LongNumberRange array data type.
Represents IntegerNumberRange array data type.
Represents ShortNumberRange array data type.
Represents ByteNumberRange array data type.
Represents Locale array data type.
Represents Currency array data type.
Represents UUID array data type.
Structure that holds a single associated-data value, which is either one of the primitive/array Evita data types (wrapped by `GrpcEvitaValue`) or a complex (structured) object.
Used in: , ,
Exactly one of these fields is set, identifying how the associated data value is encoded.
A primitive or array Evita value (see `GrpcEvitaValue`), used whenever the associated data is not a complex/structured object.
JSON-encoded `ComplexDataObject` value. Deprecated since 2025.4 - deprecated in favor of `root`: this legacy JSON encoding loses precise data type information. TOBEDONE #538: remove once no client older than 2025.4 remains in use (https://github.com/FgForrest/evitaDB/issues/538)
The root node of a complex (structured) object's tree, recursively described by `GrpcDataItem`. Used as the modern replacement for the deprecated `jsonValue` encoding.
The concrete Evita data type of the stored value, including `COMPLEX_DATA_OBJECT` when the value is a structured object described via `root` (or the deprecated `jsonValue`).
Version of this associated data value; increases on every update to enable optimistic locking (concurrent-modification detection). May be null if this value is nested within a larger complex object.
This enum contains all supported types in evitaDB query context.
Used in: , , , , ,
Represents string data type.
Represents byte data type.
Represents short data type.
Represents integer data type.
Represents long data type.
Represents boolean data type.
Represents character data type.
Represents BigDecimal data type.
Represents OffsetDateTime data type.
Represents LocalDateTime data type.
Represents LocalDate data type.
Represents LocalTime data type.
Represents DateTimeRange data type.
Represents BigDecimalNumberRange data type.
Represents LongNumberRange data type.
Represents IntegerNumberRange data type.
Represents ShortNumberRange data type.
Represents ByteNumberRange data type.
Represents Locale data type.
Represents Currency data type.
Represents UUID data type.
Represents Predecessor data type.
Represents ReferencedEntityPredecessor data type.
Represents string array data type.
Represents byte array data type.
Represents short array data type.
Represents integer array data type.
Represents long array data type.
Represents boolean array data type.
Represents character array data type.
Represents BigDecimal array data type.
Represents OffsetDateTime array data type.
Represents LocalDateTime array data type.
Represents LocalDate array data type.
Represents LocalTime array data type.
Represents DateTimeRange array data type.
Represents BigDecimalNumberRange array data type.
Represents LongNumberRange array data type.
Represents IntegerNumberRange array data type.
Represents ShortNumberRange array data type.
Represents ByteNumberRange array data type.
Represents Locale array data type.
Represents Currency array data type.
Represents UUID array data type.
Request to create a session inside of a catalog.
Used as request type in: EvitaService.CreateBinaryReadOnlySession, EvitaService.CreateBinaryReadWriteSession, EvitaService.CreateReadOnlySession, EvitaService.CreateReadWriteSession
The name of the catalog for which the session is to be created.
Default commit behaviour applied when the session is closed implicitly via `close()` - determines how far a transaction must be durably persisted before the close is considered complete. Can be overridden per call by closing the session explicitly with a specific behaviour instead. See `GrpcCommitBehavior` for the available durability/performance trade-offs.
For testing purposes. Flag indicating that all changes by the session should be rollbacked after the session is closed.
Response to a session creation request.
Used as response type in: EvitaService.CreateBinaryReadOnlySession, EvitaService.CreateBinaryReadWriteSession, EvitaService.CreateReadOnlySession, EvitaService.CreateReadWriteSession
UUID of the created session.
Type of the created session - read-only vs. read-write, and whether fetched entities are returned in binary form for the Java driver (`BINARY_*` variants). See `GrpcSessionType`.
Effective commit behaviour of the created session, applied when the session is closed implicitly via `close()`. See `GrpcCommitBehavior` for the available durability/performance trade-offs.
State of the catalog after the session was created.
UUID of the catalog the session is bound to.
Structure that holds a single attribute/default-value value together with its declared Evita data type and optimistic-locking version.
Used in: , , , , , , , , , , ,
The stored value in its wire representation; which Evita/Java type it actually represents is given by `type` below — several narrower Evita types share the same wire arm (see individual field comments). Exactly one of these fields is set when the value is non-null. When this `GrpcEvitaValue` represents an absent/null value (e.g. no default value defined for an attribute schema), none of these fields are set and `type` is left at its enum default (`STRING`), which callers must not interpret as an actual empty string value.
String value (Java `String`). Also carries a `Character` value, as a single-character string, when `type` is `CHARACTER`.
Integer value (Java `int`). Also carries `Byte` and `Short` values, widened to int32, when `type` is `BYTE` or `SHORT`.
Long value (Java `long`).
Boolean value (Java `boolean`).
BigDecimal value (Java `BigDecimal`).
DateTimeRange value (evitaDB `DateTimeRange`).
IntegerNumberRange value (evitaDB `IntegerNumberRange`). Also carries `ByteNumberRange` and `ShortNumberRange` values when `type` is `BYTE_NUMBER_RANGE` or `SHORT_NUMBER_RANGE`.
LongNumberRange value (evitaDB `LongNumberRange`).
BigDecimalNumberRange value (evitaDB `BigDecimalNumberRange`).
Date/time value (Java `OffsetDateTime`). Also carries `LocalDateTime`, `LocalDate` and `LocalTime` values when `type` is `LOCAL_DATE_TIME`, `LOCAL_DATE` or `LOCAL_TIME` respectively.
Locale value (Java `Locale`).
Currency value (Java `Currency`).
UUID value (Java `UUID`).
Predecessor value (evitaDB `Predecessor`). Also carries a `ReferencedEntityPredecessor` value when `type` is `REFERENCED_ENTITY_PREDECESSOR`.
String array value (Java `String[]`). Also carries a `Character[]` value, each element a single-character string, when `type` is `CHARACTER_ARRAY`.
Integer array value (Java `Integer[]`). Also carries `Byte[]` and `Short[]` values when `type` is `BYTE_ARRAY` or `SHORT_ARRAY`.
Long array value (Java `Long[]`).
Boolean array value (Java `Boolean[]`).
BigDecimal array value (Java `BigDecimal[]`).
DateTimeRange array value (evitaDB `DateTimeRange[]`).
IntegerNumberRange array value (evitaDB `IntegerNumberRange[]`). Also carries `ByteNumberRange[]` and `ShortNumberRange[]` values when `type` is `BYTE_NUMBER_RANGE_ARRAY` or `SHORT_NUMBER_RANGE_ARRAY`.
LongNumberRange array value (evitaDB `LongNumberRange[]`).
BigDecimalNumberRange array value (evitaDB `BigDecimalNumberRange[]`).
Date/time array value (Java `OffsetDateTime[]`). Also carries `LocalDateTime[]`, `LocalDate[]` and `LocalTime[]` values when `type` is `LOCAL_DATE_TIME_ARRAY`, `LOCAL_DATE_ARRAY` or `LOCAL_TIME_ARRAY` respectively.
Locale array value (Java `Locale[]`).
Currency array value (Java `Currency[]`).
UUID array value (Java `UUID[]`).
The concrete Evita/Java data type represented by the `value` oneof above (see each arm's comment for which narrower types it also stands in for).
Contains version of this value and gets increased with any entity type update. Allows to execute optimistic locking i.e. avoiding parallel modifications. May be null if value is used within larger complex object.
Evolution mode allows to specify how strict is evitaDB when unknown information is presented to her for the first time. When no evolution mode is set, each violation of the EntitySchema is reported by an exception. However, this behaviour can be changed by this evolution mode.
Used in: , ,
When first entity is inserted in the collection - primary key generation will automatically adapt whether this first entity has the primary key already present or not. If it is present all other entities are expected to have also primary key provided from external systems, if not primary keys will be always automatically generated by Evita and may never be provided from outside.
When new attribute is encountered, it is silently added to a collection schema as non-filterable, non-sortable, non-unique attribute of the type that was used for the first value. Localizability of the attribute is determined by the fact whether the first value encountered was associated with any localization.
When new associated data is encountered, it is silently added to a collection schema. Localizability of the associated data is determined by the fact whether the first value encountered was associated with any localization.
When new reference type is encountered, it is silently added. It's linked to other evitaDB entity when the entity type of a reference or its group respectively matches by a type of a different entity reference any existing entity collection. Reference is not indexed, nor hierarchy indexed by default and this must be changed by updating the schema.
When entity has no prices and new price is encountered, it is silently added. That means that entity type starts supporting prices when first price has been added.
When new localization is encountered, it is silently added.
When new currency is encountered in prices, it is silently added.
When hierarchy placement for the entity is encountered, it is silently added.
When a new duplicate reference is added to the entity, evitaDB automatically updates the schema to allow such duplicities. By default, references are set up with cardinality ZERO_OR_MORE
This DTO contains extra results that are computed based on the query results.
Used in:
Returns computed histograms for specific attributes based on filter constraints. A histogram is an approximate representation of the distribution of numerical data. For detailed description please see [WikiPedia](https://en.wikipedia.org/wiki/Histogram). Histogram can be computed only for numeric based properties. It visualises which property values are more common in the returned data set and which are rare. Bucket count will never exceed requested bucket count specified in `requestedCount` but there may be less of them if there is no enough data for computation. Bucket thresholds are specified heuristically so that there are as few "empty buckets" as possible. - buckets are defined by their lower bounds (inclusive) - the upper bound is the lower bound of the next bucket
Returns computed histogram for prices satisfactory to filter constraints. A histogram is an approximate representation of the distribution of numerical data. For detailed description please see [WikiPedia](https://en.wikipedia.org/wiki/Histogram). Histogram can be computed only for numeric based properties. It visualises which property values are more common in the returned data set and which are rare. Bucket count will never exceed requested bucket count specified in `requestedCount` but there may be less of them if there is no enough data for computation. Bucket thresholds are specified heuristically so that there are as few "empty buckets" as possible. - buckets are defined by their lower bounds (inclusive) - the upper bound is the lower bound of the next bucket
Contains a collection of FacetGroupStatistics DTOs where each of them contains information about single facet group (if they belong in one) and statistics of the facets that relates to it. Deprecated since 2026.2 - renamed to `referenceGroupStatistics`
Contains list of statistics for the single level (probably root or whatever is filtered by the query) of the queried hierarchy entity.
Index holds the statistics for particular references that target hierarchy entity types. Key is the identification of the reference name, value contains list of statistics for the single level (probably root or whatever is filtered by the query) of the hierarchy entity.
This DTO contains detailed information about query processing time and its decomposition to single operations.
Contains a collection of ReferenceGroupStatistics DTOs where each of them contains information about single reference group (if they belong in one) and statistics of the references that relates to it.
Enum defines various level of relationship for which the facet summary calculation rules are defined.
Used in:
Defines relation type between two facets in the same group and reference.
Defines relation type between two facets in the different groups or references.
This DTO contains information about single facet group and statistics of the facets that relates to it. Deprecated since 2026.2 - deprecated in favor of `GrpcReferenceGroupStatistics`, produced by the `referenceSummary` requirement TOBEDONE: remove when FacetSummary constraint is removed (https://github.com/FgForrest/evitaDB/issues/538)
Used in:
Contains name of the facet group.
Contains referenced entity reference representing this group.
Contains referenced entity representing this group.
Contains number of distinct entities in the response that possess any reference in this group.
Contains statistics of individual facets.
Enum defines all supported relation type that can be used in the facet summary impact calculation.
Used in:
Logical OR relation.
Logical AND relation.
Logical AND NOT relation.
Exclusive relations to other facets on the same level, when selected no other facet on that level can be selected.
This DTO contains information about single facet statistics of the entities that are present in the response.
Used in: ,
Contains referenced entity reference representing.
Contains referenced entity representing.
Contains TRUE if the facet was part of the query filtering constraints.
Contains number of distinct entities in the response that possess of this reference.
This field is not null only when this facet is not requested. Contains projected impact on the current response if this facet is also requested in filtering constraints.
Projected number of filtered entities if the query is altered by adding this facet to filtering constraint.
Selection has sense - TRUE if there is at least one entity still present in the result if the query is altered by adding this facet to filtering query. In case of OR relation between facets it's also true only if there is at least one entity present in the result when all other facets in the same group are removed and only this facet is requested.
This enum controls whether ReferenceSummary should contain only basic statistics about facets - e.g. count only, or whether the selection impact should be computed as well. Backward compatibility: `COUNTS` is kept at tag 0 (the proto3 default) and `IMPACT` at tag 1 so existing clients continue to deserialize unchanged. The newer `NONE` option is assigned a fresh tag; older clients that never request it are unaffected, and since this enum is used only as a request parameter (never as a server-emitted response), servers never push `NONE` to an unaware client.
Used in: ,
Only counts of facets will be computed.
Counts and selection impact for non-selected facets will be computed.
No per-facet statistics are computed. The engine returns facet options without counts or impact — the cheapest option, appropriate when the UI only needs to enumerate available facets without any numeric indicator. Proto3 enum values share a file-level namespace, so this value is prefixed (plain `NONE` is used by `GrpcPriceInnerRecordHandling` elsewhere in this file).
Wrapper for representing an array of FacetStatisticsDepth enums.
Used in:
The individual FacetStatisticsDepth values, in their original order.
Identification of a file available for fetching from the server (e.g. a backup archive or an export produced by an asynchronous task).
Used in: , ,
Unique identifier of the file, used to reference it in fetch/download requests.
File name, including extension.
Human-readable description of the file's purpose or contents. Unset when no description was provided.
MIME content type of the file (e.g. `application/zip`).
Size of the file on disk (bytes).
Date and time when the file was created.
Comma-separated identifiers of what produced the file — usually the `taskType` (see `GrpcTaskStatus.taskType`) of the task that created it. Unset when the origin wasn't recorded.
One node of the formula plan a query phase was carried out with - the structural counterpart of the timings. The plan is a DAG rather than a tree: a formula's result is memoized per instance, so a subtree reachable by two paths is computed once and every later occurrence of it is free. `refTo` is what keeps a reader from counting such a subtree twice - the first occurrence is described in full, and every later one is a bare node pointing back at it by id, with no children of its own. actualCost and resultCount are absent whenever the formula was not computed, which is the normal state for a rejected plan alternative and for a short-circuited branch of the winning one. They are absent rather than 0 because the plan is rendered without ever computing anything: filling them in would make asking for the plan change what the query does.
Used in:
Identity of the formula instance this node stands for, unique within the plan and stable across its occurrences - it is what makes "computed once, reused twice" visible.
Absent on the occurrence that describes the instance; equal to `id` on every later occurrence, which carries no detail and no children and means "see the node with this id".
Structural hash of the formula, i.e. what the cache keys on. Two nodes with the same hash are interchangeable computations, whereas two nodes with the same id are the same object - the two answer different questions.
Human readable description of the formula. Absent on a back-reference node.
Cost the planner estimated for this formula before running anything.
Cost the formula really incurred. Absent when it was never computed.
Number of records the formula produced. Absent when it was never computed.
Inner formulas. Always empty on a back-reference node.
The catalog-level `COMPONENT_FRAGMENTATION` component - how much of the catalog's data is still live, how fast that is getting worse, and when the engine will act on it. The compaction trigger is deterministic, so the configured thresholds that drive it are reported alongside the measurements: a data store is compacted when its file exceeds `fileSizeCompactionThresholdBytes` and either its active share is below `maxWasteActiveShare` (which overrides the interval), or below `minimalActiveRecordShare` once `minCompactionIntervalMilliseconds` has elapsed. `activeRecordShare` is NOT the share that predicate is evaluated against, and the two must not be compared. The share reported here is a catalog-wide aggregate over the bytes reported next to it, so a client can reproduce it; the trigger evaluates each data store separately against its own file length, which also carries the serialized offset-index table. They disagree in both directions - one small very wasteful file sets `compactionEligibleNow` while this aggregate stays high, and the aggregate can fall below `minimalActiveRecordShare` while no file is large enough to qualify. Take the verdict from `compactionEligibleNow` alone. `wasteBytesGenerated` counts the bytes rewrites and removals have stranded since each data store was opened or last compacted - the engine's own production counter, which is not the same quantity as `wasteBytes` and will be smaller on a freshly restarted server. The rate and the projected time extrapolate from it. An unset `estimatedCompactionAt` means no crossing follows from the current write rate - it never means "never", and a client must not substitute a date for it. Every figure here is folded across the catalog's own data store AND every collection's, so on its own it cannot say WHERE the fragmentation is. `catalogDataStore` reports the catalog's own store - schema, headers and catalog-level indexes - separately, which is what lets a raised `compactionEligibleNow` be attributed: set on the nested message means the catalog's own store is due, unset means the flag came from a collection.
Used in:
Catalog-wide `liveBytes / (liveBytes + wasteBytes)`, in the range 0..1; `1.0` when nothing is stored yet.
Active records across the catalog and all collection data stores (bytes).
Bytes compaction would reclaim (bytes).
True when at least one data store of this catalog already satisfies the compaction predicate.
Configured minimum file size below which compaction never triggers (bytes).
Bytes stranded by rewrites and removals since each data store was opened or last compacted, summed across them (bytes).
Rate at which `wasteBytesGenerated` grows, smoothed over recent flushes and decayed while nothing is being written; `0` when no waste is accruing (bytes per second).
Projected time at which the first data store that is not already eligible crosses the predicate. Unset when no crossing follows from the current rate.
Configured active share below which compaction triggers once the minimum interval has elapsed, in the range 0..1.
Configured active share below which compaction triggers regardless of the interval, in the range 0..1.
Configured minimum spacing between two compactions of the same file (milliseconds).
The same measurements for the catalog's own data store alone - the slice of every figure above that belongs to no entity collection. Always set when this component is delivered.
Response to a catalog full backup request (a backup that includes the entire catalog history, not just the current state).
Used as response type in: EvitaSessionService.FullBackupCatalog, EvitaSessionService.FullBackupCatalogWithProgress
Handle to the asynchronous backup task; use it to poll or stream the task's progress and, once finished, retrieve the resulting backup file.
This is the definition object for attributes that are stored along with catalog. Definition objects allow to describe the structure of the catalog so that in any time everyone can consult complete structure of the catalog. Definition object is similar to Java reflection process where you can also at any moment see which fields and methods are available for the class. Catalog attributes allows defining set of data that are fetched in bulk along with the catalog body. Attributes may be indexed for fast filtering or can be used to sort along. Attributes are not automatically indexed in order not to waste precious memory space for data that will never be used in search queries. Filtering in attributes is executed by using constraints like `and`, `or`, `not`. Sorting can be achieved with `attributeNatural` or others. Attributes are not recommended for bigger data as they are all loaded at once when requested.
Used in:
Contains unique name of the attribute. Case-sensitive. Distinguishes one attribute from another within a single entity type or, for global attributes, within the entire catalog.
optional description of the attribute
optional deprecation notice
When attribute is unique it is automatically filterable, and it is ensured there is exactly one single entity having certain value of this attribute among other entities in the same collection. As an example of unique attribute can be EAN - there is no sense in having two entities with same EAN, and it's better to have this ensured by the database engine. Deprecated since 2024.12 - deprecated in favor of `uniqueInScopes`
When attribute is filterable, it is possible to filter entities by this attribute. Do not mark attribute as filterable unless you know that you'll search entities by this attribute. Each filterable attribute occupies (memory/disk) space in the form of index. When attribute is filterable, extra result `attributeHistogram` can be requested for this attribute. Deprecated since 2024.12 - deprecated in favor of `filterableInScopes`
When attribute is sortable, it is possible to sort entities by this attribute. Do not mark attribute as sortable unless you know that you'll sort entities along this attribute. Each sortable attribute occupies (memory/disk) space in the form of index.. Deprecated since 2024.12 - deprecated in favor of `sortableInScopes`
When attribute is localized, it has to be ALWAYS used in connection with specific `Locale`.
When attribute is nullable, its values may be missing in the entities. Otherwise, the system will enforce non-null checks upon upserting of the entity.
If an attribute is flagged as representative, it should be used in developer tools along with the entity's primary key to describe the entity or reference to that entity. The flag is completely optional and doesn't affect the core functionality of the database in any way. However, if it's used correctly, it can be very helpful to developers in quickly finding their way around the data. There should be very few representative attributes in the entity type, and the unique ones are usually the best to choose.
Data type of the attribute. Must be one of Evita-supported values. Internally the scalar is converted into Java-corresponding data type.
Default value is used when the entity is created without this attribute specified. Default values allow to pass non-null checks even if no attributes of such name are specified.
Determines how many fractional places are important when entities are compared during filtering or sorting. It is significant to know that all values of this attribute will be converted to `Integer`, so the attribute number must not ever exceed maximum limits of `Integer` type when scaling the number by the power of ten using `indexedDecimalPlaces` as exponent.
When attribute is unique globally it is automatically filterable, and it is ensured there is exactly one single entity having certain value of this attribute in entire catalog. As an example of unique attribute can be URL - there is no sense in having two entities with same URL, and it's better to have this ensured by the database engine. Deprecated since 2024.12 - deprecated in favor of `uniqueGloballyInScopes`
Contains attribute name converted to different naming conventions.
When attribute is unique it is automatically filterable, and it is ensured there is exactly one single entity having certain value of this attribute among other entities in the same collection. As an example of unique attribute can be EAN - there is no sense in having two entities with same EAN, and it's better to have this ensured by the database engine.
When attribute is filterable, it is possible to filter entities by this attribute. Do not mark attribute as filterable unless you know that you'll search entities by this attribute. Each filterable attribute occupies (memory/disk) space in the form of index. When attribute is filterable, extra result `attributeHistogram` can be requested for this attribute.
When attribute is sortable, it is possible to sort entities by this attribute. Do not mark attribute as sortable unless you know that you'll sort entities along this attribute. Each sortable attribute occupies (memory/disk) space in the form of index..
When attribute is unique globally it is automatically filterable, and it is ensured there is exactly one single entity having certain value of this attribute in entire catalog. As an example of unique attribute can be URL - there is no sense in having two entities with same URL, and it's better to have this ensured by the database engine.
Contains the per-attribute override of the conflict resolution granularity. Defaults to inherited (follow the resolved conflict resolution).
The optional accelerations the attribute's filter index maintains, per scope. Only scopes the attribute has a filter index in - i.e. is filterable or unique in - may appear here. An empty list - which is what an older server sends - means no acceleration anywhere.
This enum represents the uniqueness type of a `GlobalAttributeSchema`. It is used to determine whether the attribute value must be unique among all the entities using this `GlobalAttributeSchema` or whether it must be unique only among entities of the same locale.
Used in: , , , ,
The attribute is not unique (default).
The attribute value (either localized or non-localized) must be unique among all values among all the entities using this `GlobalAttributeSchema` in the entire catalog.
The localized attribute value must be unique among all values of the same `Locale` among all the entities using this `GlobalAttributeSchema` in the entire catalog.
The cardinality reading of one global unique index of the catalog index.
Used in:
Name of the globally-unique attribute this index covers.
Locale this index is bound to; absent when the attribute is unique globally across every locale. A present locale means the catalog holds one such index per locale.
Scope of the catalog index holding this global unique index.
How many distinct values the index holds (values). Distinct values, not covered records. The two agree for an ordinary globally-unique attribute, where one value belongs to one record, and diverge for one that is localized as well: that has a single locale-less key covering every locale, so one record can own several values in it. Only this reading is carried here, because it is the one an O(1) counter answers; the covered-record count is reported next to it, as `GrpcAttributeCardinality.recordsCovered`, by `GetIndexDetail` - which reaches one catalog index rather than all of them.
Enum represents a sub-entity refinement of entity-level conflict detection. Granularity is legal only when the coarse conflict policy is set to entity level.
Used in:
Conflicts are detected on entity attributes.
Conflicts are detected on references.
Conflicts are detected on reference attributes.
Conflicts are detected on associated data.
Conflicts are detected on prices.
Conflicts are detected on hierarchy placement.
This enum represents the possible health problems that can be signaled by the server.
Used in:
* Signalized when the consumed memory never goes below 85% of the maximum heap size and the GC tries to free old generation at least once (this situation usually leads to repeated attempts of expensive old generation GC and pressure on system CPUs).
* Signalized when the readiness probe signals that at least one external API, that is configured to be enabled doesn't respond to internal HTTP check call.
* Signalized when the input queues are full and the server is not able to process incoming requests. The problem is reported when there is ration of rejected tasks to accepted tasks >= 2. This flag is cleared when the rejection ratio decreases below the specified threshold, which signalizes that server is able to process incoming requests again.
* Signaled when there are occurrences of Java internal errors. These errors are usually caused by the server itself and are not related to the client's requests. Java errors signal fatal problems inside the JVM.
Heartbeat message sent to the subscriber to keep the connection alive.
Used in: ,
the index of the heartbeat event
the timestamp of the heartbeat event on the server
the last observed version by the subscriber in case of system subscription it is engine version in case of catalog subscription it is catalog version
milliseconds to the next heartbeat (derived from the server configuration)
Contains list of statistics for the single level (probably root or whatever is filtered by the query) of the queried hierarchy entity.
Used in:
Map holds the statistics represented by user-specified output name of requested hierarchy.
The enumeration controls what the `hierarchyContent` requirement does with an ancestor whose requested body cannot be materialized. An ancestor may be present in the hierarchy index and still fail to yield a body: it may hold no data in the locale the query filters by, it may have been deleted, or the parent primary key may point at an entity that was never created. The chain is walked from the immediate parent upwards, and this enumeration decides what happens when the walk reaches such a node. The choice only has anything to act on when `hierarchyContent` carries an inner `entityFetch`. A bare `hierarchyContent()` requests no body at all, so nothing can fail to materialize and both values return the complete chain of parent primary keys.
Used in:
The chain is cut just below the first ancestor whose requested body cannot be materialized - that ancestor and everything above it is left out entirely, so every ancestor the caller receives carries the requested body. This is the default, and deliberately the zero value: a query parameter that is absent from the request - as it always is for a client built against a server release that predates this enumeration - therefore selects the behaviour `hierarchyContent` has always had, and can never be mistaken for `COMPLETE`.
Every ancestor is returned. One whose requested body cannot be materialized arrives as a bodyless pointer carrying nothing but its primary key, and the walk continues above it - so an ancestor carrying a body may well appear above a bodyless one. A client selecting this value must be prepared for a returned ancestor that carries no body.
Histogram can be computed only for numeric based properties. It visualises which property values are more common in the returned data set and which are rare. Bucket count will never exceed requested bucket count but there may be less of them if there is no enough data for computation. Bucket thresholds are specified heuristically so tha there are as few "empty buckets" as possible. - buckets are defined by their lower bounds (inclusive) - the upper bound is the lower bound of the next bucket
Used in: ,
Returns left bound of the first bucket. It represents the smallest value encountered in the returned set.
Returns right bound of the last bucket of the histogram. Each bucket contains only left bound threshold, so this value is necessary so that first histogram buckets makes any sense. This value is exceptional in the sense that it represents the biggest value encountered in the returned set and represents inclusive right bound for the last bucket.
Returns count of all entities that are covered by this histogram. It's plain sum of occurrences of all buckets in the histogram.
Returns histogram buckets that represents a tuple of occurrence count and the minimal threshold of the bucket values.
Referenced entity whose value anchors the minimum bucket of the histogram. Populated only for reference-scope histograms when an entity fetch is requested for the associated reference.
Referenced entity whose value anchors the maximum bucket of the histogram. Populated only for reference-scope histograms when an entity fetch is requested for the associated reference.
Data object that carries out threshold in histogram (or bucket if you will) along with number of occurrences in it.
Used in:
Contains threshold (left bound - inclusive) of the bucket.
Contains number of entity occurrences in this bucket - e.g. number of entities that has monitored property value between previous bucket threshold (exclusive) and this bucket threshold (inclusive)
Contains true if the `bucket` is overlapping the attribute between filtering constraint
Rendering intensity of the bucket's bar, on a 0-100 scale. Never a count and never a probability. For standard histograms: percentage of total occurrences, summing to 100 across the histogram. For equalized histograms: the smoothed value density at the bucket, normalised against the maximum of the density curve, so the value lies in (0, 100] where 100 is the tallest point of the distribution. These values do NOT sum to 100 and there are no empty buckets - scale bars against the constant 100, never against the sum or the tallest returned bucket.
The enum specifies whether the HistogramBehavior should produce histogram with exactly requested bucket counts or optimized one, which may have less buckets than requested, but is more compact
Used in: ,
Histogram always contains the number of buckets you asked for. This is the default behaviour. Bucket boundaries are positioned at equal intervals across the value range.
Histogram will never contain more buckets than you asked for, but may contain less when the data is scarce and there would be big gaps (empty buckets) between buckets. This leads to more compact histograms, which provide better user experience. Bucket boundaries are positioned at equal intervals across the value range.
Histogram will never contain more buckets than you asked for, and contains fewer whenever a single value is held by so many entities that it collapses several quantile intervals into one. Bucket boundaries are positioned on the empirical quantile function, so each bucket covers approximately equal portion of total records. Every boundary is a value the data actually contains, so no bucket is ever empty. `relativeFrequency` carries the smoothed value density normalised to the curve maximum, in the range (0, 100].
Deprecated: use EQUALIZED instead. Identical to EQUALIZED - the equalised algorithm never emits an empty bucket, so there is nothing for the "optimized" variant to drop; the constant is kept because it is part of the published query grammar.
Wrapper for representing an array of HistogramBehavior enums.
Used in:
The individual HistogramBehavior values, in their original order.
The `COMPONENT_HISTORY` component - how far back in time the catalog can be read, what that costs on disk, and what is stopping superseded files from going away. `activeReaderFloor` is the actionable number: superseded files at a catalog version above it cannot be deleted in either purge mode, so a floor that stops advancing is the direct explanation for disk space that will not come back. evitaLab surfaces the same number as *deletion floor*.
Used in:
True when write-ahead log retention keeps history available for time travel.
Oldest catalog version still readable; `-1` when no history is retained.
Wall-clock time of `oldestAvailableCatalogVersion`. Unset when no history is retained or the time is unknown.
Newest catalog version; `-1` when it could not be determined.
Wall-clock time of `newestCatalogVersion`. Unset when it could not be determined.
Number of retained write-ahead log files; `0` when time travel is disabled (files).
Total size of the retained write-ahead log files; `0` when time travel is disabled (bytes).
Oldest catalog version still referenced by an open reader or writer.
Number of superseded data files not yet purged (files).
Total size of those files (bytes).
The part of them pinned above `activeReaderFloor` (bytes).
The part of them nothing blocks, waiting only on the purge mechanism (bytes).
Host CDC event. Carried as the body of GrpcChangeSystemCapture when the subscriber explicitly opted in to HOST.
Used in:
Exactly one of the following event kinds is set.
Fires when a catalog's local reference settles into a non-transient state on this host.
Fires when a catalog is fully removed from the live view on this host.
Fires when a catalog's schema version increases on this host (coalesced).
What an index browse ranks its results by - the key half of the order, whose other half is the direction carried beside it in `GrpcIndexBrowseRequest.direction`. Every key walks every index of the collection; what they differ in is how much of that walk has to be kept in memory to produce a page, and what the kept entries are ranked by. The two halves are separate fields because they are separate choices: the same key read in the other direction answers the opposite question (the largest indexes or the smallest, the busiest or the untouched), and every key but map order is meaningful both ways.
Used in:
The order the indexes happen to sit in inside the collection's internal index map. Arbitrary, but stable for a given catalog version, and the cheapest way to page exhaustively through the whole set. Carries no meaning a client should read into. It holds the zero slot, so an unset `ordering` reads as "enumerate everything, cheaply" - the one answer that cannot be mistaken for a ranking the client did not ask for. It is also the one key with no ranking to reverse: it is accepted with direction `ASC` alone, which is how the walk order is spelled, and rejected with `DESC` rather than the direction being silently ignored.
`entityCount`, ties broken deterministically by index kind, then scope, then discriminator - descending for the largest indexes first, ascending for the smallest. The tiebreaker matters: index counts are heavily tied in practice, and without it successive pages would re-order the tied block and show duplicates while hiding other indexes. This is a top-N access pattern - a page is built from a bounded heap rather than a full sort, so the advantage narrows the deeper the requested page is. There is deliberately no ordering by estimated memory: entity count is a single constant-time reading, whereas a memory estimate has to traverse an index, so ordering by it would mean estimating every index in the collection on every call. A catalog browse has nothing for this key to rank by in either direction - a catalog index reports no entity count at all - so there it degenerates to the same order `INDEX_BROWSE_ORDERING_MAP_ORDER` yields, ascending as much as descending. It is accepted rather than rejected so that one client can send the same request to either.
`queryCount`, ties broken deterministically by index kind, then scope, then discriminator. Descending answers which indexes are earning the memory they occupy. Read each count against the same row's `observedSince` rather than on its own: the observation window opens per index, so two raw counts only become comparable once each has been divided by its own window. Unlike `INDEX_BROWSE_ORDERING_ENTITY_COUNT` this key is meaningful for a catalog browse too, because a catalog index is queried and maintained like any other. Ascending is the hunt for indexes that may be worth dropping, and it is dominated by ties at zero, because on most catalogs the majority of indexes have never been chosen by a query; the kind-then-scope-then-discriminator tiebreaker is the whole of what makes a page boundary drawn inside that block of zeros reproducible. A zero is not by itself a verdict - it is a statement about the window the row's `observedSince` opens. The rank is a best-effort reading taken as the walk passes each index, not a snapshot of one instant - the counters move under live traffic. Each index is read once, and the count a row reports for the counter it was ranked by is the reading that placed it, so no row contradicts its own position. Pages are nevertheless unstable across calls: recording activity does not advance the catalog version, so two pages agreeing on `catalogVersion` may still have been ranked by counters that moved between them, and one index can appear on two pages or on neither. This is a top-N access pattern - page in `INDEX_BROWSE_ORDERING_MAP_ORDER` to enumerate the whole set - and it is subject to the paging-depth limit documented on `GrpcIndexBrowseRequest.pageNumber`, in both directions.
`updateCount`, same tiebreaker. Descending, read beside `INDEX_BROWSE_ORDERING_QUERY_COUNT` descending, finds the indexes maintained far more often than they are read. Mind what `GrpcBrowsedIndex.updateCount` documents about the maintenance it counts before acting on the head of that direction: a global index leads it on essentially every catalog and is never a drop candidate, and maintenance driven by a write to another collection is not counted at all. Ascending surfaces the indexes nothing is writing to. It is dominated by ties at zero exactly as `INDEX_BROWSE_ORDERING_QUERY_COUNT` ascending is, and reproducible inside that block for the same reason. A never-updated index is not thereby a drop candidate: it may be precisely the one every query reads, so read it beside `INDEX_BROWSE_ORDERING_QUERY_COUNT` ascending rather than acting on it alone. The caveats on `INDEX_BROWSE_ORDERING_QUERY_COUNT` apply unchanged, in both directions.
The cardinality readings of one index.
Used in: ,
Type of this index. Unset when the index is one the catalog holds itself rather than an entity index: those are addressed by scope alone, because there is exactly one of them per scope, and no value of this enum describes one. `GrpcCollectionIndexCardinality` never leaves it unset - it describes a single collection - whereas `GrpcIndexDetail` does whenever it describes a catalog index.
Scope this index belongs to.
What distinguishes this index from its siblings of the same type, rendered exactly as `GrpcBrowsedIndex` renders it: the reference name for the schema-bounded reference indexes `GrpcCollectionIndexCardinality` describes, and the full rendering including representative attribute values when a `GrpcIndexDetail` describes a per-referenced-entity index. Unset for the global index, which has no sibling within its scope.
How many entities this index covers - the denominator every distinct-value count below should be read against (entities). Unset for an index the catalog holds itself, which maintains no primary-key bitmap to take a cardinality of; `0` would read as "this index covers nothing", which is a different statement. What such an index holds is reported per attribute below instead.
How many distinct referenced entities this index tracks (entities). Unset for an index that tracks none - only the reference indexes maintain a reference cardinality, and reporting `0` for the global index would read as "this collection references nothing", which is a different statement.
One entry per attribute index held by this index, in no guaranteed order.
Everything worth knowing about one index: what it occupies, and whether it is earning it. The drill-down that follows an index browse. `GrpcBrowsedIndex` says which indexes exist and how many entities each covers; this says what one of them costs and how well it discriminates. Why this describes one index and there is no collection-wide form: estimating an index's heap walks its contents, and no cache can amortise it - a measured warm second pass came back slower than the cold one. On a production catalog the largest single index took 151 ms while the median took about 4 microseconds, so naming one index is affordable and sweeping a collection of a quarter of a million of them is not. A client that wants a collection total issues these calls in parallel and sums them, which keeps the cost visible to whoever chose to pay it.
Used in:
Identity of the described index within its owner, echoed back so a response can be matched to the request that asked for it. The same opaque handle `GrpcBrowsedIndex.indexPrimaryKey` carries.
Best-effort estimate of the heap this index occupies (bytes). An estimate, computed rather than measured, and one that deliberately charges structure shared with a superseded version of an index in full - that predecessor is garbage waiting to be collected, and reporting it as free would understate what the server is holding. Validated end to end against a production catalog, where the indexes' reported total came to 11.55 GB against a 12.87 GB live heap.
How many distinct values this index holds and how many records they cover, per attribute index - the "is this index earning its keep, or is it three distinct values over two million records?" reading. Also carries the index's type, scope, discriminator and entity count, so a detail response describes itself without the browse row beside it. This is the only place a per-referenced-entity index is ever described. `GrpcCollectionIndexCardinality` counts those without describing them, because doing so would make its response grow with the catalog's data. A catalog index reaches the same fields by a different route: its attribute entries are its global unique indexes, one per globally-unique attribute per locale in use, and its `entityCount` is unset.
Name of the entity collection holding the described index. Unset for an index the catalog holds itself. Echoed back with the handle above because the two together are the index's identity - see `GrpcBrowsedIndex.entityType`.
How many executed query plans have chosen this index as part of their winning target index set - see `GrpcBrowsedIndex.queryCount` for what "chosen" excludes and for the since-catalog-load lifetime all four of these readings share.
How many entity mutations have acquired this index for modification - see `GrpcBrowsedIndex.updateCount`.
When the last query that chose this index was planned. Unset when no query has chosen it since the catalog was loaded.
When the last entity mutation that acquired this index finished applying. Unset when none has since the catalog was loaded.
Whether the readings above were taken at all. False on a server started with `server.usageStatisticsTracking: false`, which allocates no activity holder per index and lets neither the query nor the write path reach for one. A client MUST branch on this before rendering a zero. "Not measured" and "never queried" are opposite findings - only the second one says an index can be dropped - and a zero shown beside a live window asserts the second when the truth is the first. Render the absence of measurement instead, and say so. Presence-tracked on purpose. A server predating this field sends nothing, and that silence must NOT be read as "not measured": such a server had no switch to turn counting off, so it always measured and its counts are real. Absent therefore decodes as `true`. Only an explicit `false` means the operator switched counting off.
When observation of this index began, and therefore the window the two counters and the two stamps above are read against - see `GrpcBrowsedIndex.observedSince` for why it is a property of the index rather than of the catalog. A server that knows this field always sets it; absent only from a server predating it, and the window is then unknown - see `GrpcBrowsedIndex.observedSince` for why no instant may stand in for it.
The catalog-level `COMPONENT_INDEX_SUMMARY` component - how many indexes the catalog holds in total. Only a total here: the breakdown by index type and scope requires a pass over the index keys of a collection, and doing that for every collection on every polled refresh is exactly the cost this API is shaped to avoid. The breakdown is fetched per collection instead.
Used in:
Total number of indexes across the whole catalog, including the catalog-level index itself (indexes).
Number of indexes of one type within one scope.
Used in:
Type of the counted indexes.
Scope the counted indexes belong to.
How many such indexes exist (indexes).
Contains all possible infrastructure mutations in catalog.
Used in:
The mutation to be performed.
This transaction mutation delimits mutations of one transaction from another. It contains data that allow to recognize the scope of the transaction and verify its integrity.
This mutation allows to create a reference in the entity.
Used in:
Unique identifier of the reference.
Primary key of the referenced entity. Might be also any integer that uniquely identifies some external resource not maintained by Evita.
Contains information about reference cardinality. This value is usually NULL except the case when the reference is created for the first time and `EvolutionMode.ADDING_REFERENCES` is allowed.
Contains information about target entity type. This value is usually NULL except the case when the reference is created for the first time and `EvolutionMode.ADDING_REFERENCES` is allowed.
internal PK is assigned by evitaDB engine and is used to uniquely identify the reference among other references. It is used when multiple references share same business key - entityType and primaryKey - but differ by other properties (fe. reference group or attributes). When a reference is created for the first time, internal id is set to a unique negative number that is not used by the server side, which assigns positive unique numbers to the references on first reference persistence. This allows distinguishing references that are not yet persisted from those that are already persistent. When standalone key is used: - negative number: means that the reference is new and hasn't been yet persisted - zero: means we don't know the internal PK - positive number: means that the reference is persistent and has been already stored in the database
Wrapper for representing an array of integers. Also used to carry Byte and Short arrays, narrowed/widened to int32 on the wire; which Java array type applies is determined by the accompanying GrpcEvitaDataType (BYTE_ARRAY, SHORT_ARRAY or INTEGER_ARRAY).
Used in: ,
The individual integer elements, in their original order.
Representation of IntegerNumberRange structures. At least one of `from`/`to` should be set; if both are absent, the range decodes to the degenerate range `[0,0]` rather than being unbounded in both directions.
Used in: , , ,
The inclusive lower bound of the range. If unset (while `to` is set), the range is unbounded below.
The inclusive upper bound of the range. If unset (while `from` is set), the range is unbounded above.
Wrapper for representing an array of IntegerNumberRanges. Also used to carry ByteNumberRange and ShortNumberRange arrays; which Java array type applies is determined by the accompanying GrpcEvitaDataType (BYTE_NUMBER_RANGE_ARRAY, SHORT_NUMBER_RANGE_ARRAY or INTEGER_NUMBER_RANGE_ARRAY).
Used in: ,
The individual IntegerNumberRange elements, in their original order.
This DTO represents single hierarchical entity in the statistics tree. It contains identification of the entity, the cardinality of queried entities that refer to it and information about children level.
Used in:
Hierarchical entity reference at position in tree represented by this object.
Hierarchical entity at position in tree represented by this object.
Contains the number of queried entities that refer directly to this `entity` or to any of its children entities.
Contains number of hierarchical entities that are referring to this `entity` as its parent. The count will respect behaviour settings and will not count empty children in case `REMOVE_EMPTY` is used for computation.
Contains hierarchy info of the entities that are subordinate (children) of this `entity`.
Contains true if the `entity` was filtered by hierarchy within constraint
This DTO represents a wrapper for array of statistics for the single hierarchy level of inner entities.
Used in:
Array of statistics for the single hierarchy level of inner entities.
Contains all possible catalog schema mutations.
Used in: ,
The used local catalog mutation.
Mutation is responsible for setting value to a `CatalogSchema.description` in `CatalogSchema`.
Mutation is responsible for adding one or more modes to a `CatalogSchema.catalogEvolutionMode` in `CatalogSchema`.
Mutation is responsible for removing one or more modes from a `CatalogSchema.evolutionMode` in `CatalogSchema`.
Mutation is responsible for setting up a new `GlobalAttributeSchema` in the `CatalogSchema`. Mutation can be used for altering also the existing `GlobalAttributeSchema` alone.
Mutation is responsible for setting value to a `AttributeSchema.defaultValue` in `EntitySchema`. Mutation can be used for altering also the existing `AttributeSchema` or `GlobalAttributeSchema` alone.
Mutation is responsible for setting value to a `AttributeSchema.defaultValue` in `EntitySchema`. Mutation can be used for altering also the existing `AttributeSchema` or `GlobalAttributeSchema` alone.
Mutation is responsible for setting value to a `AttributeSchema.description` in `EntitySchema`. Mutation can be used for altering also the existing `AttributeSchema` or `GlobalAttributeSchema` alone.
Mutation is responsible for renaming an existing `AttributeSchema` in `EntitySchema` or `GlobalAttributeSchema` in `CatalogSchema`. Mutation can be used for altering also the existing `AttributeSchema` or `GlobalAttributeSchema` alone.
Mutation is responsible for setting value to a `AttributeSchema.type` in `EntitySchema`. Mutation can be used for altering also the existing `AttributeSchema` or `GlobalAttributeSchema` alone.
Mutation is responsible for removing an existing `AttributeSchema` in the `EntitySchema` or `GlobalAttributeSchema` in the `CatalogSchema`. Mutation can be used for altering also the existing `AttributeSchema` or `GlobalAttributeSchema` alone.
Mutation is responsible for setting value to a `AttributeSchema.filterable` in `EntitySchema`. Mutation can be used for altering also the existing `AttributeSchema` or `GlobalAttributeSchema` alone.
Mutation is responsible for setting value to a `AttributeSchema.localized`in `EntitySchema`. Mutation can be used for altering also the existing `AttributeSchema` or`GlobalAttributeSchema` alone.
Mutation is responsible for setting value to a `AttributeSchema.nullable` in `EntitySchema`. Mutation can be used for altering also the existing `AttributeSchema` or `GlobalAttributeSchema` alone.
Mutation is responsible for setting value to a `AttributeSchema.representative` in `EntitySchema`. Mutation can be used for altering also the existing `AttributeSchema` or `GlobalAttributeSchema` alone.
Mutation is responsible for setting value to a `AttributeSchema.sortable` in `EntitySchema`. Mutation can be used for altering also the existing `AttributeSchema` or `GlobalAttributeSchema` alone.
Mutation is responsible for setting value to a `AttributeSchema.unique` in `EntitySchema`. Mutation can be used for altering also the existing `AttributeSchema` or `GlobalAttributeSchema` alone.
Mutation is responsible for setting value to a `GlobalAttributeSchema.uniqueGlobally` in `EntitySchema`. Mutation can be used for altering also the existing `GlobalAttributeSchema` alone.
Mutation is responsible for setting up a new `EntitySchema` - or more precisely the collection within catalog.
Mutation is a holder for a set of `EntitySchemaMutation` that affect a single entity schema within the `CatalogSchema`.
Mutation is responsible for renaming an existing `EntitySchema`.
Mutation is responsible for removing an existing `EntitySchema` - or more precisely the entity collection instance itself.
Mutation is responsible for setting value `AttributeSchema.conflictResolutionOverride` in `CatalogSchema`.
Mutation is responsible for setting value to a `CatalogSchema.conflictResolution` in `CatalogSchema`.
Mutation is responsible for setting the filter accelerators of a `GlobalAttributeSchema` in `CatalogSchema`. Mutation can be used for altering also the existing `AttributeSchema` or `GlobalAttributeSchema` alone.
Contains all possible local mutations to perform on entity.
Used in: ,
The mutation to be performed.
Increments or decrements existing numeric value by specified delta (negative number produces decremental of existing number, positive one incrementation). Allows to specify the number range that is tolerated for the value after delta application has been finished to verify for example that number of items on stock doesn't go below zero.
Upsert attribute mutation will either update existing attribute or create new one.
Remove attribute mutation will drop existing attribute - ie.generates new version of the attribute with tombstone on it.
Upsert associatedData mutation will either update existing associatedData or create new one.
Remove associated data mutation will drop existing associatedData - ie.generates new version of the associated data with tombstone on it.
This mutation allows to create / update `price` of the entity.
This mutation allows to remove existing `price` of the entity.
This mutation allows to set / remove `priceInnerRecordHandling` behaviour of the entity.
This mutation allows to set `parent` in the `entity`.
This mutation allows to remove `parent` from the `entity`.
This mutation allows to create a reference in the entity.
This mutation allows to remove a reference from the entity.
This mutation allows to create / update group of the reference.
This mutation allows to remove group in the reference.
This mutation allows to create / update / remove attribute of the reference.
This mutation allows to set scope of the entity to ARCHIVED or LIVE state.
Structure for representing Locale objects specified by language tag.
Used in: , , , , , , , , , , , , ,
IETF BCP 47 language tag (e.g. `en-US`, `cs-CZ`), resolved server-side via `Locale#forLanguageTag(String)`.
Wrapper for representing an array of Locales.
Used in: ,
The individual Locale elements, in their original order.
This structure is used as a wrapper around the associated data map for the purpose of separation the global associated data from the localized.
Used in:
The map, where the key is the name of the associated data and the value is the associated data value. The localization is held on the entity level - specific language tag is used as a key of the outer map on the SealedEntity level.
This structure is used as a wrapper around the attribute map for the purpose of separation the global attributes from the localized ones.
Used in: ,
The map, where the key is the name of the attribute and the value is its value. The localization is held on the entity or the reference level respectively - specific language tag is used as a key of the outer map on the SealedEntity level.
This structure is used as a wrapper around the attribute map for the purpose of separation the global attributes from the localized ones.
The map, where the key is the name of the attribute and the value is the its value.
Wrapper for representing an array of longs.
Used in: ,
The individual long elements, in their original order.
Representation of LongNumberRange structures. At least one of `from`/`to` should be set; if both are absent, the range decodes to the degenerate range `[0,0]` rather than being unbounded in both directions.
Used in: , , ,
The inclusive lower bound of the range. If unset (while `to` is set), the range is unbounded below.
The inclusive upper bound of the range. If unset (while `from` is set), the range is unbounded above.
Wrapper for representing an array of LongNumberRanges.
Used in: ,
The individual LongNumberRange elements, in their original order.
Mutation that transitions a catalog to the "live" state, making it transactional.
Used in:
Name of the catalog schema the mutation is targeting (will rename).
Request to make a catalog alive.
Used as request type in: EvitaService.MakeCatalogAlive, EvitaService.MakeCatalogAliveWithProgress
Name of the catalog to make alive.
Request to make a catalog immutable.
Used as request type in: EvitaService.MakeCatalogImmutable, EvitaService.MakeCatalogImmutableWithProgress
Name of the catalog to make immutable.
Request to make a catalog mutable.
Used as request type in: EvitaService.MakeCatalogMutable, EvitaService.MakeCatalogMutableWithProgress
Name of the catalog to make mutable.
This enumeration controls behavior of the `ReferenceContent` related to managed entities. If the target entity is not (yet) present in the database and `EXISTING` is set, the reference will not be returned as if it does not exist. If `ANY` is set (default behavior), the reference will be returned if defined regardless of its target entity existence.
Used in:
The reference to managed entity will always be returned regardless of the target entity existence.
The reference to managed entity will be returned only if the target entity exists in the database.
Mutation that records the fact a catalog's on-disk folder is no longer present, so the engine can move it to `MISSING` state in lock-step with the WAL rather than silently rewriting the bootstrap file on startup reconciliation.
Used in:
Name of the catalog whose on-disk folder is no longer present.
Mutation is responsible for setting value to a `AssociatedDataSchemaContract.deprecationNotice` in `EntitySchema`. Mutation can be used for altering also the existing `AssociatedDataSchema` alone.
Used in:
Contains unique name of the model. Case-sensitive. Distinguishes one model item from another within single entity instance.
Deprecation notice contains information about planned removal of this associated data from the model / client API. This allows to plan and evolve the schema allowing clients to adapt early to planned breaking changes.
Mutation is responsible for setting value to a `AssociatedDataSchema.description` in `EntitySchema`. Mutation can be used for altering also the existing `AssociatedDataSchema` alone.
Used in:
Contains unique name of the model. Case-sensitive. Distinguishes one model item from another within single entity instance.
Contains description of the model is optional but helps authors of the schema / client API to better explain the original purpose of the model to the consumers.
Mutation is responsible for renaming an existing `AssociatedDataSchema` in `EntitySchema`. Mutation can be used for altering also the existing `AssociatedDataSchema` alone.
Used in:
Contains unique name of the model. Case-sensitive. Distinguishes one model item from another within single entity instance.
Contains unique name of the model. Case-sensitive. Distinguishes one model item from another within single entity instance.
Mutation is responsible for setting value to a `AssociatedDataSchema.type` in `EntitySchema`. Mutation can be used for altering also the existing `AssociatedDataSchema` alone.
Used in:
Contains unique name of the model. Case-sensitive. Distinguishes one model item from another within single entity instance.
Contains the data type of the entity. Must be one of supported types or may represent complex type - which is JSON object that can be automatically converted to the set of basic types.
Mutation is responsible for setting value to a `AttributeSchema.defaultValue` in `EntitySchema`. Mutation can be used for altering also the existing `AttributeSchema` or GlobalAttributeSchema` alone.
Used in: , ,
Name of the attribute the mutation is targeting.
Default value is used when the entity is created without this attribute specified. Default values allow to pass non-null checks even if no attributes of such name are specified.
Mutation is responsible for setting value to a `AttributeSchema.deprecationNotice` in `EntitySchema`. Mutation can be used for altering also the existing `AttributeSchema` or `GlobalAttributeSchema` alone.
Used in: , ,
Name of the attribute the mutation is targeting.
Deprecation notice contains information about planned removal of this attribute from the model / client API. This allows to plan and evolve the schema allowing clients to adapt early to planned breaking changes.
Mutation is responsible for setting value to a `AttributeSchema.description` in `EntitySchema`. Mutation can be used for altering also the existing `AttributeSchema` or `GlobalAttributeSchema` alone.
Used in: , ,
Name of the attribute the mutation is targeting.
Contains description of the model is optional but helps authors of the schema / client API to better explain the original purpose of the model to the consumers.
Mutation is responsible for renaming an existing `AttributeSchema` in `EntitySchema` or `GlobalAttributeSchema` in `CatalogSchema`. Mutation can be used for altering also the existing `AttributeSchema` or `GlobalAttributeSchema` alone.
Used in: , ,
Name of the attribute the mutation is targeting.
New name of the attribute the mutation is targeting.
Mutation is responsible for setting value to a `AttributeSchema.type` in `EntitySchema`. Mutation can be used for altering also the existing `AttributeSchema` or `GlobalAttributeSchema` alone.
Used in: , ,
Name of the attribute the mutation is targeting.
Type of the attribute. Must be one of supported data types or its array.
Determines how many fractional places are important when entities are compared during filtering or sorting.
Mutation is responsible for setting value to a `CatalogSchema.conflictResolution` in `CatalogSchema`.
Used in:
The catalog-level conflict resolution setting. When not set (absent), the catalog schema conflict resolution is cleared (inherits the resolved conflict resolution).
Mutation is responsible for setting value to a `CatalogSchema.description` in `CatalogSchema`.
Used in:
Contains description of the model is optional but helps authors of the schema / client API to better explain the original purpose of the model to the consumers.
Mutation is responsible for altering an existing CatalogSchema.
Used in:
Name of the catalog schema the mutation is targeting (will rename).
Collection of schema mutations that should be applied on current version of the catalog schema.
Mutation is responsible for renaming an existing CatalogSchema.
Used in:
Name of the catalog schema the mutation is targeting (will rename).
The new name of the catalog schema.
Flag indicating whether to replace the existing catalog or just to rename it.
Mutation is responsible for setting value to a `EntitySchema.conflictResolution` in `EntitySchema`.
Used in:
The entity-level conflict resolution setting. When not set (absent), the entity schema conflict resolution is cleared (inherits the resolved conflict resolution).
Mutation is responsible for setting a `EntitySchema.deprecationNotice` in `EntitySchema`.
Used in:
Deprecation notice contains information about planned removal of this entity schema from the model / client API. This allows to plan and evolve the schema allowing clients to adapt early to planned breaking changes.
Mutation is responsible for setting a `EntitySchema.description` in `EntitySchema`.
Used in:
Contains description of the model is optional but helps authors of the schema / client API to better explain the original purpose of the model to the consumers.
Mutation is a holder for a set of `EntitySchemaMutation` that affect a single entity schema within the `CatalogSchema`.
Used in: , ,
Entity type of entity schema that will be affected by passed mutations.
Collection of mutations that should be applied on current version of the schema.
Mutation is responsible for renaming an existing `EntitySchema`.
Used in: ,
Name of the entity schema the mutation is targeting.
New name of the entity schema the mutation is targeting.
Whether to overwrite entity collection with same name as the `newName` if found.
Mutation is a holder for a single `AttributeSchema` that affect any of `ReferenceSchema.attributes` in the `EntitySchema`.
Used in:
Name of the reference the mutation is targeting.
Nested attribute schema mutation that mutates reference attributes of targeted reference.
Mutation is responsible for setting value to a `ReferenceSchema.cardinality` in `EntitySchema`.
Used in:
Name of the reference the mutation is targeting.
Cardinality describes the expected count of relations of this type. In evitaDB we define only one-way relationship from the perspective of the entity. We stick to the ERD modelling [standards](https://www.gleek.io/blog/crows-foot-notation.html) here. Cardinality affect the design of the client API (returning only single reference or collections) and also help us to protect the consistency of the data so that conforms to the creator mental model.
Mutation is responsible for setting value to a `ReferenceSchema.deprecationNotice` in `EntitySchema`.
Used in:
Name of the reference the mutation is targeting.
Deprecation notice contains information about planned removal of this schema from the model / client API. This allows to plan and evolve the schema allowing clients to adapt early to planned breaking changes.
Mutation is responsible for setting value to a `ReferenceSchema.description` in `EntitySchema`. Mutation can be used for altering also the existing `ReferenceSchema` alone.
Used in:
Name of the reference the mutation is targeting.
Contains description of the model is optional but helps authors of the schema / client API to better explain the original purpose of the model to the consumers.
Mutation is responsible for renaming an existing `ReferenceSchema` in `EntitySchema`. Mutation can be used for altering also the existing `ReferenceSchema` alone.
Used in:
Name of the reference the mutation is targeting.
New name of the reference the mutation is targeting.
Mutation is responsible for setting value to a `ReferenceSchema.referencedGroupType`in `EntitySchema`.
Used in:
Name of the reference the mutation is targeting.
Reference to `EntitySchema.name` of the referenced group entity. Might be also any `String` that identifies type some external resource not maintained by Evita.
Whether `referencedGroupType` refers to any existing `EntitySchema.name` that is maintained by Evita.
Mutation is responsible for setting value to a `ReferenceSchema.referencedEntityType` in `EntitySchema`. Mutation can be used for altering also the existing `ReferenceSchema` alone.
Used in:
Name of the reference the mutation is targeting.
Reference to `EntitySchema.name` of the referenced entity. Might be also any `String` that identifies type some external resource not maintained by Evita.
Whether `referencedEntityType` refers to any existing `EntitySchema.name` that is maintained by Evita.
Mutation is a holder for a single `SortableAttributeCompoundSchema` that affect any of `ReferenceSchema.sortableAttributeCompound` in the `EntitySchema`.
Used in:
Name of the reference the mutation is targeting.
Nested sortable attribute compound schema mutation that mutates reference sortable attribute compounds of targeted reference.
Mutation is responsible for setting value to a `ReflectedReferenceSchema.attributesInherited` and `ReflectedReferenceSchema.attributesExcludedFromInheritance` in `ReferenceSchema`. Mutation can be used for altering also the existing `ReferenceSchemaContract` alone.
Used in:
Name of the reference the mutation is targeting.
Contains true if the attributes of the reflected reference are inherited from the target reference.
The array of attribute names that are inherited / excluded from inheritance based on the value of attributeInheritanceBehavior property.
Mutation is responsible for setting value to a `SortableAttributeCompoundSchema.deprecationNotice` in `EntitySchema` or `ReferenceSchema`.
Used in: ,
Name of the sortable attribute compound the mutation is targeting.
Deprecation notice contains information about planned removal of this sortable attribute compound from the model / client API. This allows to plan and evolve the schema allowing clients to adapt early to planned breaking changes.
Mutation is responsible for setting value to a `SortableAttributeCompoundSchema.description` in `EntitySchema` or `ReferenceSchema`.
Used in: ,
Name of the sortable attribute compound the mutation is targeting.
Contains description of the model is optional but helps authors of the schema / client API to better explain the original purpose of the model to the consumers.
Mutation is responsible for renaming an existing `SortableAttributeCompoundSchema` in `EntitySchema` or `ReferenceSchema`.
Used in: ,
Name of the sortable attribute compound the mutation is targeting.
New name of the sortable attribute compound the mutation is targeting.
Structure for representing a name in a particular naming convention.
Used in: , , , , , , ,
The naming convention this variant is rendered in (e.g. camelCase, kebab-case, PascalCase).
The entity/attribute/reference name transformed into the given naming convention.
Contains set of all supported/used naming conventions in evitaDB APIs.
Used in:
Camel case: https://en.wikipedia.org/wiki/Camel_case
Pascal case: https://www.theserverside.com/definition/Pascal-case
Snake case: https://en.wikipedia.org/wiki/Snake_case
Capitalized snake case: https://en.wikipedia.org/wiki/Snake_case
Kebab case: https://en.wikipedia.org/wiki/Letter_case#Kebab_case
The OffsetAndLimit record represents pagination parameters including offset, limit, and the last page number.
Used in:
The starting point for fetching records.
The number of records to fetch from the starting point.
The current page number based on the current pagination settings.
The last page number based on the current pagination settings.
The total number of records available.
Structure for universal representation of DateTime objects with an offset.
Used in: , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,
The date and time of the object internally represented by unix timestamp.
The offset of the object in seconds. Templates for offset: Z - for UTC +h +hh +hh:mm -hh:mm +hhmm -hhmm +hh:mm:ss -hh:mm:ss +hhmmss -hhmms
Wrapper for representing an array of OffsetDateTimes. Also used to carry LocalDateTime, LocalDate and LocalTime arrays; which Java array type applies is determined by the accompanying GrpcEvitaDataType (OFFSET_DATE_TIME_ARRAY, LOCAL_DATE_TIME_ARRAY, LOCAL_DATE_ARRAY or LOCAL_TIME_ARRAY).
Used in: ,
The individual date/time elements, in their original order.
Defines the behaviour of null values in an attribute element of the sortable attribute compound.
Used in:
Null values are sorted before non-null values.
Null values are sorted after non-null values.
Used in order constraints to specify ordering direction.
Used in: , , ,
Ascending order.
Descending order.
Wrapper for representing an array of OrderDirection enums.
Used in:
The individual OrderDirection values, in their original order.
Page-based pagination descriptor for a `GrpcDataChunk`, reporting the page actually returned. The desired page is requested via the query's `page()` require constraint, not a field on this response structure - see `io.evitadb.api.query.require.Page` for the full contract. `pageNumber` is 1-indexed (page 1 is the first page) - see `io.evitadb.dataType.PaginatedList#getPageNumber`. A requested page number of 0 or less is rejected by the server; a requested page number beyond `lastPageNumber` is not rejected - the engine returns the first page instead, so `pageNumber` here can differ from what was requested.
Used in:
Number of records requested per page, echoed back from the query's `page()` require constraint. Zero is valid and yields an empty page while `totalRecordCount`/`lastPageNumber` are still reported.
The page actually returned (1-indexed) - see the message-level comment for how this can differ from the requested page number.
The number of the last available page, given `pageSize` and the total record count.
Structure for representing Predecessor objects, used to express a manually maintained ordering of sibling entities/references by pointing each one at the primary key of the item that precedes it.
Used in:
If `true`, this is the first item in the ordering (no predecessor) and `predecessorId` is not set. If `false`, this item has a predecessor and `predecessorId` must be set.
The primary key of the entity/reference that precedes this one in the ordering. Unset when `head` is `true`; must be set when `head` is `false`.
Prices are specific to a very few entities, but because correct price computation is very complex in e-commerce systems and highly affects performance of the entities filtering and sorting, they deserve first class support in entity model. It is pretty common in B2B systems single product has assigned dozens of prices for the different customers.
Used in:
Contains identification of the price in the external systems. This id is expected to be used for the synchronization of the price in relation with the primary source of the prices. This id is used to uniquely find a price within same price list and currency and is mandatory.
Contains identification of the price list in the external system. Each price must reference a price list. Price list identification may refer to another Evita entity or may contain any external price list identification (for example id or unique name of the price list in the external system). Single entity is expected to have single price for the price list unless there is validity specified. In other words there is no sense to have multiple concurrently valid prices for the same entity that have roots in the same price list.
Identification of the currency.
Some special products (such as master products, or product sets) may contain prices of all "subordinate" products so that the aggregating product can represent them in certain views on the product. In that case there is need to distinguish the projected prices of the subordinate product in the one that represents them. Inner record id must contain positive value.
Price without tax.
Tax rate percentage (i.e. for 19% it'll be 19.00)
Price with tax.
Date and time interval for which the price is valid (inclusive).
Controls whether price is subject to filtering / sorting logic, non-sellable prices will be fetched along with entity but won't be considered when evaluating search. These prices may be used for "informational" prices such as reference price (the crossed out price often found on e-commerce sites as "usual price") but are not considered as the "selling" price. Deprecated since 2024.10 - RENAMED TO "indexed"
Contains version of this price and gets increased with any entity type update. Allows to execute optimistic locking i.e. avoiding parallel modifications.
Controls whether price is subject to filtering / sorting logic, non-sellable prices will be fetched along with entity but won't be considered when evaluating search. These prices may be used for "informational" prices such as reference price (the crossed out price often found on e-commerce sites as "usual price") but are not considered as the "selling" price.
Determines which prices will be fetched along with entity.
Used in: ,
No prices will be fetched.
Only prices respecting filter constraints in query will be fetched.
All prices will be fetched.
Wrapper for representing an array of PriceContentMode enums.
Used in:
The individual PriceContentMode values, in their original order.
This enum controls how prices that share same `inner entity id` will behave during filtering and sorting.
Used in: ,
No special strategy set. Inner record id is not taken into account at all.
Prices with same inner entity id will be sorted descending by priority value and first one (i.e. the one with the biggest priority) will be used (others won't be considered at all)
Prices with same inner entity id will be added up to a new computed aggregated price, prices must share same tax rate percentage, currency and price list id in order to be added up
Price handling mode that is used in cases when the information has not been fetched along with entity, and is therefore unknown (even if some strategy is associated with the entity in reality).
Client label attached to the query
Used in: , ,
The label name
The label value
Response for a query executed via QueryList, i.e. expecting a flat list of matching entities (no paging metadata - use plain `Query` via `GrpcQueryResponse` if paging is needed). Exactly one of `entityReferences`/`sealedEntities`/`binaryEntities` is the active field, chosen the same way as in `GrpcDataChunk`: no `entityFetch` requirement in the query's `require` block selects `entityReferences`; an `entityFetch` requirement selects `sealedEntities` (structured form) or `binaryEntities` (binary storage form), depending on whether the session uses the binary storage format. The other two fields are always left empty; note the active field is itself also empty when zero entities matched.
Used as response type in: EvitaSessionService.QueryList, EvitaSessionService.QueryListUnsafe
Matched entities as references (type + primary key only). See the message-level comment for when this field (vs. the other two) is the active one.
Matched entities, fully fetched in structured (non-binary) form. See the message-level comment for when this field (vs. the other two) is the active one.
Matched entities, fully fetched in the server's binary storage format. See the message-level comment for when this field (vs. the other two) is the active one.
Response for a query executed via QueryOne, i.e. expecting zero or one matching entity. At most one of `entityReference`/`sealedEntity`/`binaryEntity` is populated. If an entity matched, which one is chosen the same way as in `GrpcDataChunk`: no `entityFetch` requirement in the query's `require` block yields `entityReference`; an `entityFetch` requirement yields `sealedEntity` (structured form) or `binaryEntity` (binary storage form), depending on whether the session uses the binary storage format. If no entity matched the query, all three fields are left unset - this is not an error.
Used as response type in: EvitaSessionService.QueryOne, EvitaSessionService.QueryOneUnsafe
The matched entity as a reference (type + primary key only). See the message-level comment for when this field (vs. the other two) is populated.
The matched entity, fully fetched in structured (non-binary) form. See the message-level comment for when this field (vs. the other two) is populated.
The matched entity, fully fetched in the server's binary storage format. See the message-level comment for when this field (vs. the other two) is populated.
Structure that supports storing all possible parameters that could be used within query.
Used in: , , , , , ,
Exactly one of the following arms must be set. An unset `queryParam` is a client error: `QueryConverter.convertQueryParam` dispatches on the set arm and throws `EvitaInvalidUsageException` if none matches. Positional parameters (query strings using `?` placeholders) bind to entries of the enclosing message's `positionalQueryParams` list in the order the `?` placeholders are encountered in the query text — the first `?` binds to index 0, and so on. A query with more `?` placeholders than available entries fails with `EvitaInvalidUsageException("Missing argument of index N.")`. Named parameters (query strings using `@name` placeholders) bind to entries of the enclosing message's `namedQueryParams` map by the name embedded in the query text. A placeholder with no matching key fails with `EvitaInvalidUsageException("Missing argument of name `name`.")`.
Binds a string parameter into the query, e.g. a string literal compared by `attributeEquals`, `attributeContains` or similar constraints, or a classifier name (entity type, attribute name).
Binds an `int32` parameter into the query, typically used for primary keys or numeric literals.
Binds a `long` parameter into the query, typically used for primary keys or numeric literals that exceed the `int32` range.
Binds a boolean parameter into the query.
Binds an arbitrary-precision decimal parameter into the query, typically used for price or other monetary/decimal literals.
Binds a date-time range parameter into the query, e.g. used with `entityValidIn`/`priceValidIn` style constraints that test whether a given instant falls within a validity range.
Binds an `int32` range parameter into the query, e.g. used with `between`-style range constraints.
Binds a `long` range parameter into the query, e.g. used with `between`-style range constraints.
Binds an arbitrary-precision decimal range parameter into the query, e.g. used with `between`- style range constraints over prices or other decimal values.
Binds a single point-in-time parameter (date, time and offset) into the query, e.g. used with `priceValidIn` to test price validity at a specific instant.
Binds a `Locale` parameter into the query, e.g. used with `entityLocaleEquals`.
Binds a `Currency` parameter into the query, e.g. used with `priceInCurrency`.
Binds a `GrpcFacetStatisticsDepth` enum parameter into the query, e.g. used with the `facetSummary` requirement to select whether only counts or also selection impact is computed.
Binds a `GrpcQueryPriceMode` enum parameter into the query, used by price-related filtering constraints to select whether tax-inclusive or tax-exclusive prices are considered. Field name is a legacy typo ("Model" instead of "Mode"); kept as-is because renaming would break generated accessors and JSON field mapping for existing clients.
Binds a `GrpcPriceContentMode` enum parameter into the query, e.g. used with the `priceContent` requirement to select which prices are fetched along with the entity.
Binds a `GrpcAttributeSpecialValue` enum parameter into the query, e.g. used with `attributeIs` to test whether an attribute value is `NULL` or `NOT_NULL`.
Binds a `GrpcOrderDirection` enum parameter into the query, e.g. used with `attributeNatural` and other ordering constraints to select ascending or descending order.
Binds a `GrpcEmptyHierarchicalEntityBehaviour` enum parameter into the query, used by hierarchy statistics requirements to select whether hierarchy nodes with no referring entities are kept in or removed from the result tree.
Binds a `GrpcStatisticsBase` enum parameter into the query, used by hierarchy statistics requirements to select which part of the `filterBy` constraint is considered when computing cardinalities.
Binds a `GrpcStatisticsType` enum parameter into the query, used by hierarchy statistics requirements to select whether children counts or queried-entity counts are produced.
Binds a `GrpcHistogramBehavior` enum parameter into the query, used by histogram requirements to select whether the histogram always has exactly the requested bucket count or an optimized, more compact bucket layout.
Binds a `GrpcManagedReferencesBehaviour` enum parameter into the query, used by the `referenceContent` requirement to select whether references to a managed entity that no longer exists are still returned.
Binds a raw EvitaQL expression string into the query, evaluated via `ExpressionFactory` — e.g. used as the size argument of the `gap` requirement to compute spacing between paginated results.
Binds a `GrpcEntityScope` enum parameter into the query, used by scope-aware constraints to select whether live or archived entities are considered.
Binds a `GrpcFacetRelationType` enum parameter into the query, used by facet summary impact calculation to select the logical relation (disjunction, conjunction, negation, exclusivity) applied between facets.
Binds a `GrpcFacetGroupRelationLevel` enum parameter into the query, used by facet summary impact calculation to select whether the relation applies between facets in the same group or across different groups/references.
Binds a `GrpcTraversalMode` enum parameter into the query, used by the `traverseByEntityProperty` ordering constraint to select depth-first or breadth-first traversal.
Binds a `GrpcHierarchyParentsBehaviour` enum parameter into the query, used by the `hierarchyContent` requirement to select what happens to an ancestor whose requested body cannot be materialized - whether the parent chain is cut below it, or continues above it with that ancestor reported as a bodyless pointer. A query that leaves the argument out simply carries no placeholder for it, so no entry of this arm is sent at all and the requirement keeps its own default, `MATCHING`.
Binds a list of string parameters into the query, e.g. used with `inSet`-style constraints such as `attributeInSet` over string-typed attributes.
Binds a list of `int32` parameters into the query, e.g. used with `entityPrimaryKeyInSet` or `attributeInSet` over integer-typed attributes.
Binds a list of `long` parameters into the query, e.g. used with `inSet`-style constraints over long-typed values that exceed the `int32` range.
Binds a list of boolean parameters into the query, e.g. used with `inSet`-style constraints over boolean-typed attributes.
Binds a list of arbitrary-precision decimal parameters into the query, e.g. used with `inSet`-style constraints over decimal-typed attributes.
Binds a list of date-time range parameters into the query, e.g. used with `inSet`-style constraints over range-typed attributes.
Binds a list of `int32` range parameters into the query, e.g. used with `inSet`-style constraints over integer-range-typed attributes.
Binds a list of `long` range parameters into the query, e.g. used with `inSet`-style constraints over long-range-typed attributes.
Binds a list of arbitrary-precision decimal range parameters into the query, e.g. used with `inSet`-style constraints over decimal-range-typed attributes.
Binds a list of point-in-time parameters into the query, e.g. used with `inSet`-style constraints over date-time-typed attributes.
Binds a list of `Locale` parameters into the query, e.g. used to enumerate multiple locales in a single constraint or requirement.
Binds a list of `Currency` parameters into the query, e.g. used to enumerate multiple currencies in a single constraint or requirement.
Binds a list of `GrpcFacetStatisticsDepth` enum parameters into the query, used where the placeholder resolves to a list rather than a single value.
Binds a list of `GrpcQueryPriceMode` enum parameters into the query, used where the placeholder resolves to a list rather than a single value.
Binds a list of `GrpcPriceContentMode` enum parameters into the query, used where the placeholder resolves to a list rather than a single value.
Binds a list of `GrpcAttributeSpecialValue` enum parameters into the query, used where the placeholder resolves to a list rather than a single value.
Binds a list of `GrpcOrderDirection` enum parameters into the query, used where the placeholder resolves to a list rather than a single value.
Binds a list of `GrpcEmptyHierarchicalEntityBehaviour` enum parameters into the query, used where the placeholder resolves to a list rather than a single value.
Binds a list of `GrpcStatisticsBase` enum parameters into the query, used where the placeholder resolves to a list rather than a single value.
Binds a list of `GrpcStatisticsType` enum parameters into the query, used where the placeholder resolves to a list rather than a single value.
Binds a list of `GrpcHistogramBehavior` enum parameters into the query, used where the placeholder resolves to a list rather than a single value.
Binds a list of `GrpcEntityScope` enum parameters into the query, e.g. used with constraints that accept multiple scopes (live, archived) at once.
Enum contains all query execution phases, that leads from request to response.
Used in:
Entire query execution time.
Entire planning phase of the query execution.
Planning phase of the inner query execution.
Determining which indexes should be used.
Creating formula for filtering entities.
Creating formula for nested query.
Creating alternative formula for filtering entities.
Creating formula for sorting result entities.
Creating alternative formula for sorting result entities.
Creating factories for requested extra results.
Creating factories for requested extra results based on alternative indexes.
Entire query execution phase.
Prefetching entities that should be examined instead of consulting indexes.
Computing entities that should be returned in output (filtering).
Computing entities within nested query that should be returned in output (filtering).
Sorting output entities and slicing requested page.
Fabricating requested extra results.
Fabricating requested single extra result.
Fetching rich data from the storage based on computed entity primary keys.
Fetching referenced entities and entity groups from the storage based on referenced primary keys information.
Fetching parent entities from the storage based on parent primary keys information.
Aggregate phase covering orchestration of all referenced entity loads (predicate setup, ID collection, dedup, recursive dispatch).
Determines which price will be used for filtering.
Used in: ,
Price computation operations will use actual price with tax added for filtering.
Price computation operations will use actual price without tax added for filtering.
Wrapper for representing an array of QueryPriceModeArray enums.
Used in:
The individual QueryPriceMode values, in their original order.
Request for specifying a full EvitaQL query (filter, order and require blocks) to be executed.
Used as request type in: EvitaSessionService.Query, EvitaSessionService.QueryList, EvitaSessionService.QueryOne
The string part of the parametrised query, e.g. `query(collection('Product'), filterBy(entityPrimaryKeyInSet(?)))`. Parameter values are not embedded in this string but supplied separately via `positionalQueryParams`/ `namedQueryParams` below. A `?` placeholder is a positional parameter, an `@name` placeholder is a named parameter - see `positionalQueryParams` for the full binding contract, which applies identically here.
Values for the `?` positional placeholders in `query`, bound in encounter order: the first `?` in the parsed string binds to `positionalQueryParams[0]`, the second to `positionalQueryParams[1]`, and so on (FIFO). Supplying fewer values than there are `?` placeholders fails the request with "Missing argument of index N."; extra values are ignored.
Values for the `@name` named placeholders in `query`, keyed by the name used after `@` in the string (without the `@` prefix). An `@name` placeholder with no matching map entry fails the request with "Missing argument of name `name`."; extra map entries are ignored.
Response to Query request.
Used as response type in: EvitaSessionService.Query, EvitaSessionService.QueryUnsafe
The fetched page or strip of entities (in whichever of the three representations the query's `require` block asked for - see `GrpcDataChunk`).
Extra results computed by `require` constraints beyond the entity page itself (facet summary, hierarchy statistics, price histograms, etc.). Unset (default) if the query's `require` block requested none of these.
This DTO contains detailed information about query processing time and its decomposition to single operations.
Used in:
Phase of the query processing.
Number of nanoseconds elapsed since the root step of this telemetry tree began - the root step itself therefore always reports 0. This is not a wall-clock timestamp and must not be rendered as a date.
Internal steps of this telemetry step (operation decomposition).
Arguments of the processing phase.
Duration in nanoseconds, covering this step and everything nested below it.
Wall-clock instant at which the query began. Set only on the root step - it anchors the whole tree in time, so the wall-clock position of any other node is startedAt plus that node's start offset.
Duration in nanoseconds this step spent on its own work - its spentTime less the time accounted for by its direct children. A parent's spentTime is not the sum of its children's, so this is the number that says how much of a phase is the phase itself rather than the phases inside it. This is a server-derived convenience, not part of the telemetry object's identity: the engine does not track it, and the Java driver does not reconstruct it when it rebuilds the tree from this message. It is emitted so that clients which consume the wire format directly do not each have to sum the children themselves.
Typed numeric measurements recorded for this step - cardinalities, costs and I/O counters the engine computed while answering the query. Unlike `arguments`, which is prose, these are values a client can compare and chart without parsing English. Absent when nothing was measured for this step, which is the case for every step but the root.
Structure of the formula this phase built or ran. Present only when the query asked for it with queryTelemetry(PLAN), and then only on the phases that own a formula: each PLANNING_FILTER_ALTERNATIVE step carries the candidate it costed - including the ones that lost - and the root carries the plan that ran.
Typed numeric measurements recorded for a single query telemetry step. Every field is optional and absence is meaningful: a metric is recorded where the engine happens to compute the number, so a missing one means "not measured for this phase". That is deliberately distinct from a measured 0, which recordsReturned, ioFetchCount, ioFetchedSizeBytes and prefetched can all legitimately be - which is also why these are `optional` rather than plain scalars, since proto3 implicit presence cannot tell the two apart.
Used in:
How many records the planner expected the filtering formula to match. Compare against actualCardinality - an estimate that is orders of magnitude off is why the engine chose the index it chose, and it is the usual explanation for a plan that looks wrong.
How many records the filtering formula really matched, before the requested page was cut out of them. This counts what the filter found, not what was returned - recordsReturned is the latter.
Cost the planner estimated for the filtering formula it chose. This is the unitless scale candidate indexes are ranked on - comparable between plans of the same query, meaningless in absolute terms. Absent when the estimate overflowed.
Cost the filtering formula really incurred, computed from the real cardinalities once it ran. Compare against estimatedCost on the same scale. Absent when the formula was never computed.
How many records were actually handed back, i.e. the size of the page cut out of actualCardinality. Legitimately 0 for a query whose requested page lies past the end of the result.
How many times the storage was read while assembling the response. Legitimately 0 - a query answered entirely from indexes, or one returning bare primary keys, never touches storage.
How many bytes were read from the storage while assembling the response. Reported alongside ioFetchCount because many small reads and one large read cost very differently.
Whether the planner prefetched entity bodies and filtered over them instead of consulting indexes. It explains the shape of the rest of the profile rather than measuring anything: a prefetched query spends its time in EXECUTION_PREFETCH and barely touches the index phases.
Request for specifying a full EvitaQL query with parameter values embedded directly in the string (no separate positional/named parameter binding). Internal/unsafe use only - see the `QueryUnsafe` RPC comment: applications should use `GrpcQueryRequest` instead.
Used as request type in: EvitaSessionService.QueryListUnsafe, EvitaSessionService.QueryOneUnsafe, EvitaSessionService.QueryUnsafe
The complete query string, with any parameter values already embedded (no `?`/`@name` placeholders to resolve).
Enum representing overall readiness state of the server API.
Used in:
* At least one API is not ready.
* All APIs are ready.
* At least one API that was ready is not ready anymore.
* Server is shutting down. None of the APIs are ready.
* Unknown state - cannot determine the state of the APIs (should not happen).
The catalog-level `COMPONENT_RECORD_COUNTS` component - how many entities the catalog holds, split by scope. `totalRecords` counts entity body storage parts and archiving an entity does not remove its body storage part, so the historically shipped total is live plus archived combined. It keeps that meaning here for backward compatibility; `liveRecords` and `archivedRecords` are the numbers a caller usually wants.
Used in:
Live plus archived entities across all collections of the catalog (records).
Entities residing in the live scope (records).
Entities residing in the archive scope (records).
References may carry additional key-value data linked to this entity relation (fe. item count present on certain stock).
Used in:
Name of the reference
Contains version of this reference and gets increased with any entity type update. Allows to execute optimistic locking i.e. avoiding parallel modifications.
Returns entity reference of the referenced entity in case its fetching was requested via entityFetch constraint.
Returns body of the referenced entity in case its fetching was requested via entityFetch constraint.
Returns the referenced entity in case its fetching was requested via entityGroupFetch constraint.
Returns entity reference of the referenced entity in case its fetching was requested via entityGroupFetch constraint.
Returns body of the referenced entity in case its fetching was requested via entityGroupFetch constraint.
Contains global attributes.
Contains localized attributes.
Contains reference cardinality.
internal PK is assigned by evitaDB engine and is used to uniquely identify the reference among other references. It is used when multiple references share same business key - entityType and primaryKey - but differ by other properties (fe. reference group or attributes). When a reference is created for the first time, internal id is set to a unique negative number that is not used by the server side, which assigns positive unique numbers to the references on first reference persistence. This allows distinguishing references that are not yet persisted from those that are already persistent. When standalone key is used: - negative number: means that the reference is new and hasn't been yet persisted - zero: means we don't know the internal PK - positive number: means that the reference is persistent and has been already stored in the database
This mutation allows to create / update / remove attribute of the reference.
Used in:
Unique identifier of the reference.
Primary key of the referenced entity. Might be also any integer that uniquely identifies some external resource not maintained by Evita.
One attribute mutation to update / insert / delete single attribute of the reference.
internal PK is assigned by evitaDB engine and is used to uniquely identify the reference among other references. It is used when multiple references share same business key - entityType and primaryKey - but differ by other properties (fe. reference group or attributes). When a reference is created for the first time, internal id is set to a unique negative number that is not used by the server side, which assigns positive unique numbers to the references on first reference persistence. This allows distinguishing references that are not yet persisted from those that are already persistent. When standalone key is used: - negative number: means that the reference is new and hasn't been yet persisted - zero: means we don't know the internal PK - positive number: means that the reference is persistent and has been already stored in the database
This DTO contains information about single reference group and statistics of the references that relates to it.
Used in:
Contains name of the facet group.
Contains referenced entity reference representing this group.
Contains referenced entity representing this group.
Contains number of distinct entities in the response that possess any reference in this group.
Contains statistics of individual facets.
Contains named histogram statistics for this reference group. Each histogram index defined on the reference schema produces a separate histogram entry keyed by the histogram index name.
Enum represents the type of index that should be created and maintained for a reference.
Used in:
Reference has no index available.
Reference has only basic index available that is necessary for ReferenceHaving constraint interpretation.
Reference has basic index available and also partitioning indexes for the main entity type.
Enum represents the reference components that should be indexed for a reference.
Used in:
The referenced entity itself is indexed.
The referenced group entity is indexed.
Represents a pair of reference keys used for tracking reassigned internal primary keys. The 'original' key contains the temporary internal PK, while the 'reassigned' key contains the permanent internal PK assigned after persistence.
Used in:
Name of the reference (e.g., "category", "brand"). References the reference schema name that defines the type of relationship.
Primary key of the referenced entity. May be either an evitaDB entity primary key or an external resource identifier.
Original reference key with temporary internal primary key (negative number).
Reassigned reference key with permanent internal primary key (positive number) assigned by the server.
This is the definition object for reference that is stored along with entity. Definition objects allow to describe the structure of the entity type so that in any time everyone can consult complete structure of the entity type. The references refer to other entities (of same or different entity type). Allows entity filtering (but not sorting) of the entities by using `facet_{name}_inSet` query and statistics computation if when requested. Reference is uniquely represented by int positive number (max. (2^63)-1) and entity type and can be part of multiple reference groups, that are also represented by int and entity type. Reference id in one entity is unique and belongs to single reference group id. Among multiple entities reference may be part of different reference groups. Referenced entity type may represent type of another Evita entity or may refer to anything unknown to Evita that posses unique int key and is maintained by external systems (fe. tag assignment, group assignment, category assignment, stock assignment and so on). Not all these data needs to be present in Evita. References may carry additional key-value data linked to this entity relation (fe. item count present on certain stock).
Used in:
Contains unique name of the model. Case-sensitive. Distinguishes one model item from another within single entity instance.
Contains description of the model is optional but helps authors of the schema / client API to better explain the original purpose of the model to the consumers.
Deprecation notice contains information about planned removal of this entity from the model / client API. This allows to plan and evolve the schema allowing clients to adapt early to planned breaking changes. If notice is `null`, this schema is considered not deprecated.
Cardinality describes the expected count of relations of this type. In evitaDB we define only one-way relationship from the perspective of the entity. We stick to the ERD modelling [standards](https://www.gleek.io/blog/crows-foot-notation.html) here. Cardinality affect the design of the client API (returning only single reference or collections) and also help us to protect the consistency of the data so that conforms to the creator mental model.
Reference to `Entity.type` of the referenced entity. Might be also any `String` that identifies type some external resource not maintained by Evita.
Contains `true` if `entityType` refers to any existing entity that is maintained by Evita. Deprecated since 2024.10 - use referencedEntityTypeManaged instead
Reference to `Entity.type` of the referenced entity. Might be also `String` that identifies type some external resource not maintained by Evita.
Contains `true` if `groupType` refers to any existing entity that is maintained by Evita. Deprecated since 2024.10 - use referencedGroupTypeManaged instead
Contains `true` if the index for this reference should be created and maintained allowing to filter by `reference_{reference name}_having` filtering constraints. Index is also required when reference is `faceted`. Do not mark reference as faceted unless you know that you'll need to filter/sort entities by this reference. Each indexed reference occupies (memory/disk) space in the form of index. When reference is not indexed, the entity cannot be looked up by reference attributes or relation existence itself, but the data can be fetched. Deprecated since 2024.12 - deprecated in favor of `indexedInScopes`
Contains `true` if the statistics data for this reference should be maintained and this allowing to get `facetStatistics` for this reference or use `facet_{reference name}_inSet` filtering constraint. Do not mark reference as faceted unless you want it among `facetStatistics`. Each faceted reference occupies (memory/disk) space in the form of index. Reference that was marked as faceted is called Facet. Deprecated since 2024.12 - deprecated in favor of `facetedInScopes`
Attributes related to reference allows defining set of data that are fetched in bulk along with the entity body. Attributes may be indexed for fast filtering (`AttributeSchema.filterable`) or can be used to sort along (`AttributeSchema.filterable`). Attributes are not automatically indexed in order not to waste precious memory space for data that will never be used in search queries. Filtering in attributes is executed by using constraints like `and`, `not`, `attributeEquals`, `attributeContains` and many others. Sorting can be achieved with `attributeNatural` or others. Attributes are not recommended for bigger data as they are all loaded at once.
Contains index of definitions of all sortable attribute compounds defined in this schema.
Contains reference name converted to different naming conventions.
Contains referenced entity name converted to different naming conventions (only for non-managed entities).
Contains referenced group name converted to different naming conventions (only for non-managed entities).
Contains `true` if `entityType` refers to any existing entity that is maintained by Evita.
Contains `true` if `groupType` refers to any existing entity that is maintained by Evita.
Name of the reflected reference of the target referencedEntityType(). The referenced entity must contain reference of such name and this reference must target the entity where the reflected reference is defined, and the target entity must be managed on both sides of the relation.
Contains true if the description of the reflected reference is inherited from the target reference.
Contains true if the deprecated flag of the reflected reference is inherited from the target reference.
Contains true if the cardinality of the reflected reference is inherited from the target reference.
Contains true if the faceted property settings of the reflected reference is inherited from the target reference.
Contains true if the attributes of the reflected reference are inherited from the target reference.
The array of attribute names that are inherited / excluded from inheritance based on the value of attributeInheritanceBehavior property.
Contains true if the indexed property settings of the reflected reference is inherited from the target reference.
Contains `true` if the index for this reference should be created and maintained allowing to filter by `reference_{reference name}_having` filtering constraints. Index is also required when reference is `faceted`. Do not mark reference as faceted unless you know that you'll need to filter/sort entities by this reference. Each indexed reference occupies (memory/disk) space in the form of index. When reference is not indexed, the entity cannot be looked up by reference attributes or relation existence itself, but the data can be fetched. Deprecated since 2025.6 - deprecated in favor of `scopedIndexTypes`
Contains `true` if the statistics data for this reference should be maintained and this allowing to get `facetStatistics` for this reference or use `facet_{reference name}_inSet` filtering constraint. Do not mark reference as faceted unless you want it among `facetStatistics`. Each faceted reference occupies (memory/disk) space in the form of index. Reference that was marked as faceted is called Facet.
Scoped reference index types that define both the scope and the type of index for the reference. This replaces the deprecated `indexedInScopes` field with more granular control over indexing.
Scoped reference indexed components that specify which parts of a reference relationship (referenced entity, referenced group entity) are indexed per scope.
Contains true if the indexed components property settings of the reflected reference is inherited from the target reference.
Per-scope expressions that narrow which entities participate in faceting.
Per-scope bucketed histogram configurations defining index name and value expression.
Per-scope expressions that narrow which entities participate in bucketed histogram computation.
Contains the per-reference override of the conflict resolution granularity. Defaults to inherited (follow the resolved conflict resolution). On reflected references this is always inherited.
Remove associated data mutation will drop existing associatedData - ie.generates new version of the associated data with tombstone on it.
Used in:
Unique name of the associatedData. Case-sensitive. Distinguishes one associated data item from another within single entity instance.
Contains locale in case the associatedData is locale specific.
Mutation is responsible for removing an existing `AssociatedDataSchema` in the `EntitySchema`. Mutation can be used for altering also the existing `AssociatedDataSchema` alone.
Used in:
Contains unique name of the model. Case-sensitive. Distinguishes one model item from another within single entity instance.
Remove attribute mutation will drop existing attribute - ie.generates new version of the attribute with tombstone on it.
Used in: ,
Unique name of the attribute. Case-sensitive. Distinguishes one associated data item from another within single entity instance.
Contains locale in case the attribute is locale specific.
Mutation is responsible for removing an existing `AttributeSchema` in the `EntitySchema` or `GlobalAttributeSchema` in the `CatalogSchema`. Mutation can be used for altering also the existing `AttributeSchema` or `GlobalAttributeSchema` alone.
Used in: , ,
Name of the attribute the mutation is targeting.
Mutation is responsible for removing an existing CatalogSchema.
Used in:
Name of catalog schema to remove.
Mutation is responsible for removing an existing `EntitySchema`.
Used in: ,
Name of entity schema to remove.
This mutation allows to remove `parent` from the `entity`.
Used in:
(message has no fields)
This mutation allows to remove an existing `price` of the entity, identified by price ID, price list and currency.
Used in:
Contains identification of the price in the external systems. This id is expected to be used for the synchronization of the price in relation with the primary source of the prices. This id is used to uniquely find a price within same price list and currency and is mandatory.
Contains identification of the price list in the external system. Each price must reference a price list. Price list identification may refer to another Evita entity or may contain any external price list identification (for example id or unique name of the price list in the external system). Single entity is expected to have single price for the price list unless there is `validity` specified. In other words there is no sense to have multiple concurrently valid prices for the same entity that have roots in the same price list.
Identification of the currency. Three-letter form according to [ISO 4217](https://en.wikipedia.org/wiki/ISO_4217).
This mutation allows to remove group in the reference.
Used in:
Unique identifier of the reference.
Primary key of the referenced entity. Might be also any integer that uniquely identifies some external resource not maintained by Evita.
internal PK is assigned by evitaDB engine and is used to uniquely identify the reference among other references. It is used when multiple references share same business key - entityType and primaryKey - but differ by other properties (fe. reference group or attributes). When a reference is created for the first time, internal id is set to a unique negative number that is not used by the server side, which assigns positive unique numbers to the references on first reference persistence. This allows distinguishing references that are not yet persisted from those that are already persistent. When standalone key is used: - negative number: means that the reference is new and hasn't been yet persisted - zero: means we don't know the internal PK - positive number: means that the reference is persistent and has been already stored in the database
This mutation allows to remove a reference from the entity.
Used in:
Unique identifier of the reference.
Primary key of the referenced entity. Might be also any integer that uniquely identifies some external resource not maintained by Evita.
internal PK is assigned by evitaDB engine and is used to uniquely identify the reference among other references. It is used when multiple references share same business key - entityType and primaryKey - but differ by other properties (fe. reference group or attributes). When a reference is created for the first time, internal id is set to a unique negative number that is not used by the server side, which assigns positive unique numbers to the references on first reference persistence. This allows distinguishing references that are not yet persisted from those that are already persistent. When standalone key is used: - negative number: means that the reference is new and hasn't been yet persisted - zero: means we don't know the internal PK - positive number: means that the reference is persistent and has been already stored in the database
Mutation is responsible for removing an existing `ReferenceSchema` in the `EntitySchema`. Mutation can be used for altering also the existing `ReferenceSchema` alone.
Used in:
Name of the reference the mutation is targeting.
Mutation is responsible for removing an existing `SortableAttributeCompound` in the `EntitySchema` or `ReferenceSchema`.
Used in: ,
Name of the sortable attribute compound the mutation is targeting.
Request to rename a catalog.
Used as request type in: EvitaService.RenameCatalog, EvitaService.RenameCatalogWithProgress
Name of the catalog to be renamed.
New name of the catalog.
Request to replace a catalog.
Used as request type in: EvitaService.ReplaceCatalog, EvitaService.ReplaceCatalogWithProgress
Name of the source catalog whose content takes over. After a successful replace, this name no longer exists - the catalog is consumed and its content is now served under `catalogNameToBeReplaced`. If the operation fails, the state of this catalog is unknown and must be treated as damaged.
Name of the target catalog to replace. Its existing content is dropped and replaced by the content of `catalogNameToBeReplacedWith`, while the name itself is preserved and keeps serving requests under it. If the operation fails, this catalog is guaranteed to remain untouched.
A single reserved keyword that cannot be used as a classifier of the given type (e.g. as an entity type, attribute name, or reference name) - client-side validation of user-supplied classifiers can use this list to reject collisions early, before the server does.
Used in:
The kind of classifier this keyword is reserved against (e.g. entity type, attribute name).
The reserved keyword in its normalized (camelCase) form. A candidate classifier is considered colliding if it matches this value in any of evitaDB's supported naming conventions (camelCase, PascalCase, snake_case, UPPER_SNAKE_CASE, kebab-case), not just this exact form.
The individual words `classifier` is composed of, used to detect a collision across the supported naming conventions regardless of separator or case.
Response to a catalog restore request. Returned by both `RestoreCatalog` and `RestoreCatalogFromServerFile`.
Used as response type in: EvitaManagementService.RestoreCatalog, EvitaManagementService.RestoreCatalogFromServerFile
Total number of bytes read from the backup file (bytes). Only meaningful for `RestoreCatalog`, where it reports the cumulative size of the uploaded stream; always 0 for `RestoreCatalogFromServerFile`, which does not populate this field.
The task tracking the restore operation; poll its status (`GetTaskStatus`) to observe restore progress.
Mutation is responsible for restoring a CatalogSchema in INACTIVE state.
Used in:
Name of catalog schema to restore.
One flag of a schema element, and one line of maintenance cost the workload either justifies or does not. The values are named after the schema flags they report - `filterable()`, `sortable()`, `unique()` - which is what separates them from `GrpcAttributeIndexType`, whose values name the physical index structure a cardinality reading came from. Dropping a flag here takes every physical structure maintaining it with it, and the two axes do not correspond even where their names meet: a unique attribute that is not filterable carries `SCHEMA_CAPABILITY_FILTERABLE`, because a filter against it is served from its uniqueness index - while no filter index exists for it at all. Keeping the two apart is the whole point of the schema-capability surface - see `GrpcSchemaCapabilityUsage`. The values span every schema flag whose maintenance a physical index pays for, and which of them a row can carry is fixed by its `GrpcSchemaElementKind`: an attribute has three, a sortable compound exactly one, a reference three of its own, and the entity two. Nothing outside that set is reported, because a flag no index maintains costs nothing to keep and is therefore not a thing an operator would act on.
Used in:
Default value, never sent by the server. Every reported row carries an explicit capability.
The element can be filtered by - `filterable()`, and the inverted indexes it costs. A unique attribute carries this capability too, because uniqueness implies filterability and a filter is served from the uniqueness index.
The element can be ordered by - `sortable()`, and the sorted record arrays it costs.
The element's values are unique - `unique()`, whether within the entity collection or globally, and the uniqueness index it costs.
The reference can be filtered and summarised as a facet - `faceted()`, and the facet index it costs. Carried by a `SCHEMA_ELEMENT_KIND_REFERENCE` row.
The reference is indexed - `indexed()`, and the reduced entity indexes and reference cardinality index it costs. Carried by a `SCHEMA_ELEMENT_KIND_REFERENCE` row. This is the widest flag reported here, and the one to read most carefully: dropping it takes the whole reduced index family for that reference with it, so every filter, ordering and fetch path reaching *through* the reference stops being answerable - not merely slower. A low request count means far less here than the same number on an attribute's `filterable()`.
The reference's referenced-entity counts are kept in a bucketed histogram - `bucketed()`, and that index's maintenance. Carried by a `SCHEMA_ELEMENT_KIND_REFERENCE` row.
The entity's hierarchy placement is indexed - `withHierarchy()` in an indexed scope, and the hierarchy index it costs. Carried by a `SCHEMA_ELEMENT_KIND_ENTITY` row.
The entity's prices are indexed - `withPrice()` in an indexed scope, and the price indexes it costs. Carried by a `SCHEMA_ELEMENT_KIND_ENTITY` row.
The element's filter index also answers substring matching - `filterable().acceleratedFor(AttributeFilterAccelerator.SUBSTRING_SEARCH)`, and the trigram index it costs. Carried by a `SCHEMA_ELEMENT_KIND_ATTRIBUTE` row, always *alongside* `SCHEMA_CAPABILITY_FILTERABLE` rather than instead of it: the acceleration is strictly additive, so an attribute carrying this one is filterable too and the two rows describe two separately-droppable costs. Read them together - a high filterable count with a near-zero count here says the attribute is filtered often but almost never by `attributeContains` or `attributeEndsWith`, which is exactly the reading that justifies dropping the capability while keeping the attribute filterable.
How often one schema capability was asked for by queries, against how often mutations had to maintain it - the reading that answers "you never filter by EAN, so why are you paying to keep its filter index up to date?". One row describes one capability flag, on one schema element, in one scope: `filterable()` on the entity attribute `ean` in the live scope, `sortable()` on the `categories` reference's `priority` attribute, and so on. That is the granularity an operator can act on, because the remedial action is a schema mutation which removes every physical index maintaining the flag at once. `requestedCount` is not physical index usage, and must never be presented as such. `GrpcBrowsedIndex.queryCount` counts the times one physical index was in the winning target index set of an executed plan - "is this index earning the heap it occupies?" - and deliberately excludes a candidate index the planner probed and then discarded. `requestedCount` counts the times a logical query asked for this capability, whichever plan won - "would dropping this flag from the schema break somebody's query?" - and for that question a losing candidate plan is not a false positive at all: the query named the element, so removing the flag would have made it invalid regardless of which index ended up serving it. The two disagree by design. It is counted once per logical query, not once per candidate plan. The one caveat is the server's plan-verification debug modes, which build and execute a query's alternative plans a second time to compare their results: that re-executes genuine physical work, which the per-index counters see, but the capability is still counted once because one logical query was issued. Why this is a separate surface from `GrpcIndexDetail`: a capability is maintained by many physical indexes at once - a filterable entity attribute has a filter index in the global index and in every reduced index that carries it - so these counts are an aggregate over all of them. No per-index row can carry one without either double counting it across the collection's rows or attributing a collection-wide reading to a single index, and pairing a collection-wide aggregate with one index's cost on the same row invites the wrong reading. Read the two side by side; they are not merged.
Used in:
Name of the entity collection whose schema declares the element. Unset for a row the catalog owns itself - the capabilities of a globally-unique attribute the catalog schema declares. Those live on the catalog because a query filtering by such an attribute may name no collection at all, being served from the catalog's own global unique index, and because dropping the flag is a catalog schema mutation. A catalog-owned row always carries `SCHEMA_ELEMENT_KIND_ATTRIBUTE` and an unset `containerName`: a catalog schema declares no references and no compounds.
What kind of schema element this row describes - the only thing telling an attribute apart from a sortable compound carrying the same name in the same container.
Name of the reference the element is declared on. Unset when the entity - or the catalog - declares it directly, rather than naming an unnamed reference. Attribute names are unique within their owner and not across owners, so `priority` on the entity and `priority` on the `categories` reference are routinely both present and are different elements.
Name of the attribute or sortable compound itself.
Which of the element's flags this row counts.
The scope whose indexes maintain the capability. A flag may be declared for the live data set and the archive independently, and so may be dropped from one and kept in the other.
How many logical queries asked for this capability since the server loaded the catalog (queries). Read the message comment before acting on it, and never present it as physical index earning.
How many entity mutations touched the element since the server loaded the catalog (entity mutations). Deduplicated per entity mutation rather than per affected index: one upsert writing an attribute that lives in the global index and five reduced indexes is one, not six. The fan-out width is a legitimately different metric - "physical maintenance operations" - and `GrpcBrowsedIndex.updateCount` is where it is visible. Like the per-index counters this measures work performed, including work a later rollback undoes, because the maintenance was paid either way.
When the last query asking for this capability was planned. Unset when none has since the catalog was loaded - which is a statement about the observation window rather than about the capability's whole life. Accurate to the second: the stamp is not rewritten while the recorded instant already falls in the current second, which is what keeps a capability requested thousands of times a second down to one store.
When the last entity mutation touching the element finished applying. Unset when none has since the catalog was loaded, and coarsened to the second exactly like `lastRequestedAt`.
Whether the readings above were taken at all. False on a server started with `server.usageStatisticsTracking: false`, which resolves no capability holder on the query or the write path. The row still states that the capability IS DECLARED, which is worth reporting on its own; only its counts and stamps carry no information. A client MUST branch on this before rendering a zero. "Not measured" and "never queried" are opposite findings - only the second one says a flag can be dropped - and a zero shown beside a live window asserts the second when the truth is the first. Render the absence of measurement instead, and say so. Presence-tracked on purpose. A server predating this field sends nothing, and that silence must NOT be read as "not measured": such a server had no switch to turn counting off, so it always measured and its counts are real. Absent therefore decodes as `true`. Only an explicit `false` means the operator switched counting off.
When observation of this capability began - catalog load for one the schema already declared, the schema mutation itself for one declared later. Always set: a capability is observed from the moment it comes into existence, so unlike the two stamps above there is no "not yet" case. It is the denominator the two counts are read against. Dividing either by the time elapsed since this instant states a lifetime average rate, and it is what qualifies a zero into something actionable: "not requested in the twenty minutes since this flag was added" is a statement an operator can act on, where a bare zero is not. An element dropped from the schema and added back starts over with a fresh window, because the capability genuinely was not maintained in between.
What kind of schema element one schema-capability usage row describes. Deliberately not split by owner - an entity attribute and a reference attribute are the same kind of thing declared in two places, and `GrpcSchemaCapabilityUsage.containerName` already says which place. What this separates is the things that would otherwise be indistinguishable: an attribute and a sortable compound may carry the same name in the same container, and a reference is both a container of elements and an element in its own right.
Used in:
Default value, never sent by the server. Every reported row carries an explicit kind.
An attribute, of the entity, of one of its references, or of the catalog schema itself.
A sortable attribute compound, of the entity or of one of its references.
A reference itself rather than something declared on it - the element carrying `indexed()`, `faceted()` and `bucketed()`. `containerName` is empty on such a row and `elementName` holds the reference name, because a reference is declared by the entity schema directly and has no container of its own. Not to be confused with a row about an attribute *of* that reference, which names it in `containerName` instead.
The entity itself - the element carrying `withHierarchy()` and `withPrice()`. Both are declared on the entity schema rather than on anything inside it, so `containerName` is empty and `elementName` repeats the entity type.
The optional filter accelerators an attribute declares in one particular scope. The attribute must also have a filter index in that very scope - it must be filterable or unique there - because accelerating an index that does not exist is not a state the engine can be in.
Used in: , , , ,
scope of entities in which the listed accelerators are maintained
the accelerators maintained in that scope. An empty list is meaningful - it says "no acceleration in this scope", which is what every attribute declared before this axis existed means.
uniqueness type associated with particular scope
Used in: , , , ,
scope of entities where uniqueness is enforced
type of uniqueness
Message representing a per-scope expression that narrows which entities participate in bucketed histogram computation.
Used in: , , ,
The scope in which the bucketed partially expression applies.
The expression that narrows which entities participate in bucketed histogram for this scope. When absent (not set), no partial bucketing filter is applied for this scope.
Message representing a per-scope expression that narrows which entities participate in faceting.
Used in: , , ,
The scope in which the faceted partially expression applies.
The expression that narrows which entities participate in faceting for this scope. When absent (not set), no partial faceting filter is applied for this scope.
uniqueness type associated with particular scope
Used in: , , ,
scope of entities where uniqueness is enforced
type of uniqueness
Message representing a per-scope bucketed histogram configuration that defines the index name and optional value expression computing the bucket value for each referenced entity.
Used in: , , ,
The scope in which the bucketed histogram configuration applies.
The name identifying the histogram index.
Server-generated variants of nameOfTheIndex in different naming conventions. Populated only on schema output; ignored when present on mutation input.
The expression computing the histogram bucket value for each referenced entity. When absent (not set), no value expression is defined for this scope.
Partition selector. Among references already eligible per the reference- or scope-level bucketedPartially gate, this expression decides whether the referenced entity is assigned to this specific histogram. Multiple histograms on the same reference may declare overlapping or disjoint predicates; overlap is allowed but means a record participates in every histogram whose predicate evaluates to true. When absent (not set), no per-histogram restriction applies and the histogram contains every referenced entity already eligible per the gate.
Message representing a scoped reference index type that combines scope and index type.
Used in: , , ,
The scope in which the reference index type is applied.
The type of index that should be created and maintained for the reference.
Message representing scoped reference indexed components that specify which parts of a reference relationship are indexed per scope.
Used in: , , ,
The scope in which the indexed components configuration applies.
The reference components that should be indexed in the given scope.
Based on our experience we've designed following data model for handling entities in evitaDB. Model is rather complex but was designed to limit amount of data fetched from database and minimize an amount of data that are indexed and subject to search.
Used in: , , , , , , , , , , , , , , , ,
Type of entity. Entity type is main sharding key - all data of entities with same type are stored in separated collections. Within the entity type entity is uniquely represented by primary key.
Unique Integer positive number representing the entity. Can be used for fast lookup for entity (entities). Primary key must be unique within the same entity type.
Contains version of this entity and gets increased with any entity type update. Allows to execute optimistic locking i.e. avoiding parallel modifications.
Contains version of this entity schema and gets increased with any entity type update. Allows to execute optimistic locking i.e. avoiding parallel modifications.
Primary key of parent entity.
A parent entity reference with its parent hierarchy chain.
A parent entity with its parent hierarchy chain.
Contains global attributes.
Contains localized attributes.
Prices allows defining set of prices of entity for complex filtering and ordering.
Price for which the entity should be sold. This method can be used only when appropriate price related constraints are present so that `currency` and `priceList` priority can be extracted from the query. The moment is either extracted from the query as well (if present) or current date and time is used.
Price inner record handling controls how prices that share same `inner entity id` will behave during filtering and sorting.
Returns a collection of References of this entity. The references represent relations to other evitaDB entities or external entities in different systems.
Contains global associated data.
Contains localized associated data.
Contains set of all locales that were used for localized attributes or associated data of this particular entity.
Identifies scope where the entity resides (either live or archived scope).
Contains total count of references per reference name. This may differ from count of provided references if pagination or strip was used in the input query.
Contains prices that has been requested to be calculated beside the main price for sale.
Lowest selling price (or component price for `SUM` strategy) computed with the same currency / valid-in / price-list filters as `priceForSale`. Populated when the price-range-for-sale is available on the entity. The exact semantics depend on the price inner record handling strategy: - `NONE`: equal to `priceForSale`. - `LOWEST_PRICE`: equal to `priceForSale` (the cheapest per-inner-record selling price). - `SUM`: cheapest per-inner-record component price (`priceForSale` is the cumulated sum).
Highest selling price (or component price for `SUM` strategy) computed with the same currency / valid-in / price-list filters as `priceForSale`. Populated when the price-range-for-sale is available on the entity. The exact semantics depend on the price inner record handling strategy: - `NONE`: equal to `priceForSale`. - `LOWEST_PRICE`: most expensive per-inner-record selling price. - `SUM`: most expensive per-inner-record component price (`priceForSale` is the cumulated sum).
The `COMPONENT_SESSIONS` component - how many sessions are currently open against this catalog. Read-write sessions matter beyond their own count: an open read-write session pins a catalog version, which keeps superseded data files from being purged. Pair a stubbornly non-zero `activeReadWriteSessions` with the history component's `blockedByActiveReaderBytes` when disk space refuses to come back.
Used in:
Total number of sessions currently open against the catalog (sessions).
Sessions opened in read-only mode (sessions).
Sessions opened in read-write mode (sessions).
This enum is used to identify session type of the created session by gRPC server.
Used in:
Classic read-only session.
Classic read-write session.
Read only session that returns all fetched entities in a form of a `BinaryEntity`, which has all of its data represented in a binary form. Should be used only in combination with evitaDB's Java driver.
Read write session that returns all fetched entities in a form of a `BinaryEntity`, which has all of its data represented in a binary form. Should be used only in combination with evitaDB's Java driver.
Mutation is responsible for setting value to a `AssociatedDataSchema.conflictResolutionOverride` in `EntitySchema`. Mutation can be used for altering also the existing `AssociatedDataSchema` alone.
Used in:
Contains unique name of the model. Case-sensitive. Distinguishes one model item from another within single entity instance.
The per-associated-data override of the conflict resolution granularity.
Mutation is responsible for setting value to a `AssociatedDataSchema.localized` in `EntitySchema`. Mutation can be used for altering also the existing `AssociatedDataSchema` alone.
Used in:
Contains unique name of the model. Case-sensitive. Distinguishes one model item from another within single entity instance.
Localized associated data has to be ALWAYS used in connection with specific `locale`. In other words - it cannot be stored unless associated locale is also provided.
Mutation is responsible for setting value to a `AssociatedDataSchema.nullable` in `EntitySchema`. Mutation can be used for altering also the existing `AssociatedDataSchema` alone.
Used in:
Contains unique name of the model. Case-sensitive. Distinguishes one model item from another within single entity instance.
When associated data is nullable, its values may be missing in the entities. Otherwise, the system will enforce non-null checks upon upserting of the entity.
Mutation is responsible for setting the optional filter accelerators of an `AttributeSchema` in `EntitySchema`, and of a `GlobalAttributeSchema` in `CatalogSchema`. The mutation is a full statement of the accelerator axis - it names every scope that should carry an accelerator once it is applied, and a scope it does not name ends up with none.
Used in: , ,
Name of the attribute the mutation is targeting.
The optional accelerations the attribute's filter index maintains, per scope. Only scopes the attribute has a filter index in - i.e. is filterable or unique in - may appear here. An empty list means no acceleration anywhere, which is what every attribute declared before this axis existed means.
Mutation is responsible for setting value to a `AttributeSchema.conflictResolutionOverride` in `EntitySchema`. Mutation can be used for altering also the existing `AttributeSchema` or `GlobalAttributeSchema` alone.
Used in: , ,
Name of the attribute the mutation is targeting.
The per-attribute override of the conflict resolution granularity.
Mutation is responsible for setting value to a `AttributeSchema.filterable` in `EntitySchema`. Mutation can be used for altering also the existing `AttributeSchema` or `GlobalAttributeSchema` alone.
Used in: , ,
Name of the attribute the mutation is targeting.
When attribute is filterable, it is possible to filter entities by this attribute. Do not mark attribute as filterable unless you know that you'll search entities by this attribute. Each filterable attribute occupies (memory/disk) space in the form of index. Deprecated since 2024.12 - deprecated in favor of `filterableInScopes`
When attribute is filterable, it is possible to filter entities by this attribute. Do not mark attribute as filterable unless you know that you'll search entities by this attribute. Each filterable attribute occupies (memory/disk) space in the form of index.
Mutation is responsible for setting value to a `GlobalAttributeSchema.uniqueGlobally` in `EntitySchema`. Mutation can be used for altering also the existing `GlobalAttributeSchema` alone.
Used in:
Name of the attribute the mutation is targeting.
When attribute is unique globally it is automatically filterable, and it is ensured there is exactly one single entity having certain value of this attribute in entire catalog. Deprecated since 2024.12 - deprecated in favor of `uniqueGloballyInScopes`
When attribute is unique globally it is automatically filterable, and it is ensured there is exactly one single entity having certain value of this attribute in entire catalog.
Mutation is responsible for setting value to a `AttributeSchema.localized` in `EntitySchema`. Mutation can be used for altering also the existing `AttributeSchema` or `GlobalAttributeSchema` alone.
Used in: , ,
Name of the attribute the mutation is targeting.
Localized attribute has to be ALWAYS used in connection with specific `locale`. In other words - it cannot be stored unless associated locale is also provided.
Mutation is responsible for setting value to a `AttributeSchema.nullable` in `EntitySchema`. Mutation can be used for altering also the existing `AttributeSchema` or `GlobalAttributeSchema` alone.
Used in: , ,
Name of the attribute the mutation is targeting.
When attribute is nullable, its values may be missing in the entities. Otherwise, the system will enforce non-null checks upon upserting of the entity.
Mutation is responsible for setting value to a `AttributeSchema.representative` in `EntitySchema`. Mutation can be used for altering also the existing `AttributeSchema` or `GlobalAttributeSchema` alone.
Used in: , ,
Name of the attribute the mutation is targeting.
When attribute is representative, its values may be missing in the entities. Otherwise, the system will enforce non-null checks upon upserting of the entity.
Mutation is responsible for setting value to a `AttributeSchema.sortable` in `EntitySchema`. Mutation can be used for altering also the existing `AttributeSchema` or `GlobalAttributeSchema` alone.
Used in: , ,
Name of the attribute the mutation is targeting.
When attribute is sortable, it is possible to sort entities by this attribute. Do not mark attribute as sortable unless you know that you'll sort entities along this attribute. Each sortable attribute occupies (memory/disk) space in the form of index. Deprecated since 2024.12 - deprecated in favor of `sortableInScopes`
When attribute is sortable, it is possible to sort entities by this attribute. Do not mark attribute as sortable unless you know that you'll sort entities along this attribute. Each sortable attribute occupies (memory/disk) space in the form of index.
Mutation is responsible for setting value to a `AttributeSchema.unique` in `EntitySchema`. Mutation can be used for altering also the existing `AttributeSchema` or `GlobalAttributeSchema` alone.
Used in: , ,
Name of the attribute the mutation is targeting.
When attribute is unique it is automatically filterable, and it is ensured there is exactly one single entity having certain value of this attribute among other entities in the same collection. Deprecated since 2024.12 - deprecated in favor of `uniqueInScopes`
When attribute is unique it is automatically filterable, and it is ensured there is exactly one single entity having certain value of this attribute among other entities in the same collection.
Mutation that sets the mutability state of a catalog.
Used in:
Name of the catalog to modify.
Whether the catalog should be mutable (read-write) or immutable (read-only).
Mutation that sets the active state of a catalog.
Used in:
Name of the catalog to modify.
Whether the catalog should be active or inactive.
Mutation is responsible for setting a `EntitySchema.withGeneratedPrimaryKey` in `EntitySchema`.
Used in:
Whether primary keys of entities of this type will not be provided by the external systems and Evita is responsible for generating unique primary keys for the entity on insertion. Generated key is guaranteed to be unique, but may not represent continuous ascending series. Generated key will be always greater than zero.
Mutation is responsible for setting a `EntitySchema.withHierarchy` in `EntitySchema`.
Used in:
Whether entities of this type are organized in a tree like structure (hierarchy) where certain entities are subordinate of other entities. Entities may be organized in hierarchical fashion. That means that entity may refer to single parent entity and may be referred by multiple child entities. Hierarchy is always composed of entities of same type. Each entity must be part of at most single hierarchy (tree). Hierarchy can limit returned entities by using filtering constraints `hierarchy_{reference name}_within`. It's also used for computation of extra data - such as `hierarchyParents`.
Contains set of all scopes the entity is indexed in and can be used for filtering entities and computation of extra data. If the hierarchy information is not indexed, it is still available on the entity itself (i.e. entity can define its parent entity), but it is not possible to work with the hierarchy information in any other way (calculating parent chain, children, siblings, etc.).
Mutation is responsible for setting a `EntitySchema.withPrice` in `EntitySchema`.
Used in:
Whether entities of this type holds price information. Prices are specific to a very few entities, but because correct price computation is very complex in e-commerce systems and highly affects performance of the entities filtering and sorting, they deserve first class support in entity model. It is pretty common in B2B systems single product has assigned dozens of prices for the different customers. Specifying prices on entity allows usage of `priceValidIn`, `priceInCurrency` `priceBetween`, and `priceInPriceLists` filtering constraints and also price ordering of the entities. Additional requirements `priceHistogram` and `priceType` can be used in query as well.
Determines how many fractional places are important when entities are compared during filtering or sorting. It is important to know that all prices will be converted to `Integer`, so any of the price values (either with or without tax) must not ever exceed maximum limits of `Integer` type when scaling the number by the power of ten using `indexedPricePlaces` as exponent.
Contains set of all scopes the price information is indexed in and can be used for filtering entities and computation of extra data. If the price information is not indexed, it is still available on the entity itself (i.e. entity can define its price), but it is not possible to work with the price information in any other way (calculating price histogram, filtering, sorting by price, etc.). Prices can be also set as non-indexed individually via the individual price's own `indexed` flag.
This mutation allows to set scope of the entity to ARCHIVED or LIVE state.
Used in:
The new scope of the entity.
This mutation allows to set `parent` in the `entity`.
Used in:
Optional new primary key of parent entity. If null, this entity is at the root of hierarchy.
This mutation allows to set / remove `priceInnerRecordHandling` behaviour of the entity.
Used in:
Price inner record handling controls how prices that share same `inner entity id` will behave during filtering and sorting.
This mutation allows to create / update group of the reference.
Used in:
Unique identifier of the reference.
Primary key of the referenced entity. Might be also any integer that uniquely identifies some external resource not maintained by Evita.
Type of the referenced entity representing group. Might be also any `String` that identifies type in some external resource not maintained by Evita.
Primary key of the referenced entity representing group. Might be also any integer that uniquely identifies some external resource not maintained by Evita.
internal PK is assigned by evitaDB engine and is used to uniquely identify the reference among other references. It is used when multiple references share same business key - entityType and primaryKey - but differ by other properties (fe. reference group or attributes). When a reference is created for the first time, internal id is set to a unique negative number that is not used by the server side, which assigns positive unique numbers to the references on first reference persistence. This allows distinguishing references that are not yet persisted from those that are already persistent. When standalone key is used: - negative number: means that the reference is new and hasn't been yet persisted - zero: means we don't know the internal PK - positive number: means that the reference is persistent and has been already stored in the database
Mutation is responsible for setting bucketed histogram configuration on a `ReferenceSchema` in `EntitySchema`. Mutation can be used for altering also the existing `ReferenceSchema` alone.
Used in:
Name of the reference the mutation is targeting.
Per-scope bucketed histogram configurations defining index name and value expression.
Per-scope expressions that narrow which entities participate in bucketed histogram computation.
Mutation is responsible for setting value to a `ReferenceSchema.conflictResolutionOverride` in `EntitySchema`. Mutation can be used for altering also the existing `ReferenceSchema` alone.
Used in:
Name of the reference the mutation is targeting.
The per-reference override of the conflict resolution granularity.
Mutation is responsible for setting value to a `ReferenceSchema.faceted in `EntitySchema`. Mutation can be used for altering also the existing `ReferenceSchema` alone.
Used in:
Name of the reference the mutation is targeting.
Whether the statistics data for this reference should be maintained and this allowing to get `referenceSummary` for this reference or use `facet_{reference name}_inSet` filtering query. Do not mark reference as faceted unless you want it among `FacetStatistics`. Each faceted reference occupies (memory/disk) space in the form of index. Reference that was marked as faceted is called Facet. Deprecated since 2024.12 - deprecated in favor of `facetedInScopes`
Set to true when the faceted property should be inherited from the original. This property makes sense only for inherited reference attributes on reflected reference. For all other cases it must be left as false. When set to TRUE the value of `faceted` field is ignored.
Whether the statistics data for this reference should be maintained and this allowing to get `referenceSummary` for this reference or use `facet_{reference name}_inSet` filtering query. Do not mark reference as faceted unless you want it among `FacetStatistics`. Each faceted reference occupies (memory/disk) space in the form of index. Reference that was marked as faceted is called Facet.
Per-scope expressions that narrow which entities participate in faceting. When absent (not set), expressions are inherited for reflected references.
Mutation is responsible for setting value to a `ReferenceSchema.indexed` in `EntitySchema`. Mutation can be used for altering also the existing `ReferenceSchema` alone.
Used in:
Name of the reference the mutation is targeting.
Set to true when the filterable property should be inherited from the original. This property makes sense only for inherited reference attributes on reflected reference. For all other cases it must be left as false. When set to TRUE the value of `filterable` field is ignored.
Whether the index for this reference should be created and maintained allowing to filter by `referenceHaving` filtering constraints. Index is also required when reference is `faceted`. Do not mark reference as faceted unless you know that you'll need to filter / sort entities by this reference. Each indexed reference occupies (memory/disk) space in the form of index. When reference is not indexed, the entity cannot be looked up by reference attributes or relation existence itself, but the data is loaded alongside other references if requested. Deprecated since 2025.6 - deprecated in favor of `scopedIndexTypes`
Scoped reference index types that define both the scope and the type of index for the reference. This replaces the deprecated `indexedInScopes` field with more granular control over indexing. When `inherited` is true, this field is ignored.
Scoped reference indexed components that specify which parts of a reference relationship (referenced entity, referenced group entity) are indexed per scope. When `inherited` is true, this field is ignored.
Mutation is responsible for setting set of scopes for indexing value in a `SortableAttributeCompoundSchema` in `EntitySchema`.
Used in: ,
Name of the sortable attribute compound the mutation is targeting.
When attribute sortable compound is indexed, it is possible to sort entities by this calculated attribute compound. This property contains set of all scopes this attribute compound is indexed in.
Sortable attribute compounds are used to sort entities or references by multiple attributes at once. evitaDB requires a pre-sorted index in order to be able to sort entities or references by particular attribute or combination of attributes, so it can deliver the results as fast as possible. Sortable attribute compounds are filtered the same way as attributes - using natural ordering constraint.
Used in: ,
Contains unique name of the model. Case-sensitive. Distinguishes one model item from another within single entity instance.
Contains description of the model is optional but helps authors of the schema / client API to better explain the original purpose of the model to the consumers.
Deprecation notice contains information about planned removal of this entity from the model / client API. This allows to plan and evolve the schema allowing clients to adapt early to planned breaking changes. If notice is `null`, this schema is considered not deprecated.
Collection of attribute elements that define the sortable compound. The order of the elements is important, as it defines the order of the sorting.
Contains attribute compound name converted to different naming conventions.
Contains true if the attribute was inherited from the original object via reflected reference relation
When attribute sortable compound is indexed, it is possible to sort entities by this calculated attribute compound. This property contains set of all scopes this attribute compound is indexed in.
Mutation of a sortable attribute compound schema.
Used in:
Type of the mutation. Exactly one of the following must be set.
Mutation is responsible for setting up a new `SortableAttributeCompoundSchema` in the `EntitySchema`.
Mutation is responsible for modifying a deprecation notice of an existing `SortableAttributeCompoundSchema` in the `EntitySchema`.
Mutation is responsible for modifying a description of an existing `SortableAttributeCompoundSchema` in the `EntitySchema`.
Mutation is responsible for renaming an existing `SortableAttributeCompoundSchema` in the `EntitySchema`.
Mutation is responsible for removing an existing `SortableAttributeCompoundSchema` in the `EntitySchema`.
Mutation is responsible for setting value `SortableAttributeCompoundSchema.indexedInScopes` in the `EntitySchema`.
The enum specifies whether the hierarchy statistics cardinality will be based on a complete query filter by constraint or only the part without user defined filter.
Used in: ,
Complete `filterBy` constraint output will be considered when calculating statistics of the queried entities.
Contents of the `filterBy` excluding `userFilter` and its children will be considered when calculating statistics of the queried entities.
Complete `filterBy` constraint output excluding constraints within `userFilter` limiting references of the same hierarchical entity type this constraint is applied to will be considered when calculating statistics of the queried entities.
Wrapper for representing an array of StatisticsBase enums.
Used in:
The individual StatisticsBase values, in their original order.
The enum specifies whether the HierarchyStatistics should produce the hierarchy children count or referenced entity count.
Used in: ,
The statistics will be produce a hierarchy children count.
The statistics will be produce a reference entity count.
Wrapper for representing an array of StatisticsType enums.
Used in:
The individual StatisticsType values, in their original order.
The catalog-level `COMPONENT_STORAGE_COMPOSITION` component - where the bytes of the catalog's own data store (schemas, catalog-level indexes) go, per storage-part type. Measured in bytes rather than record counts, because counts can invert the answer: a store holding 500k small attribute parts and 2k large associated-data blobs reads as attribute-dominated by count while being associated-data-dominated by bytes. Counts are reported alongside so the average per type is exact. There is deliberately no cross-collection sum - adding up records of different storage-part types from different data stores produces a number with no operational meaning. One collection's histogram is fetched by naming it.
Used in:
One entry per storage-part type present in the catalog's own data store.
Which kind of data one storage-part type holds. This is the classification a composition table groups by, and it exists because `GrpcStoragePartUsage.storagePartType` cannot serve as one: that field is the simple class name of a storage part, an OPEN set that grows whenever the engine gains an index structure, and nothing in a name says which entries are indexes - two of the engine's index parts carry no `Index` in their class name at all. This set is CLOSED on purpose. A new storage-part type is expected to land in an existing group, so a client that knows these values keeps rendering a correct table across engine versions without being taught anything; adding a value here is a deliberate, documented event rather than a side effect of adding a part type. The index groups mirror the data groups on purpose - `ATTRIBUTE_DATA` against `ATTRIBUTE_INDEX`, `PRICE_DATA` against `PRICE_INDEX`, `REFERENCE_DATA` against `REFERENCE_INDEX`. The pair is what a schema owner reads to see what indexing a feature costs against what storing it costs.
Used in:
Default value, never sent by the server. Every reported storage-part type carries an explicit group.
The entity's own record - primary key, scope, locales, parent and the manifest of the parts it owns.
Attribute values as stored, one record per entity and locale.
Associated data values as stored. Usually the largest data group - this is where documents and images end up.
Prices as stored, one record per entity.
References to other entities as stored, including their own attributes.
An index's own record rather than the values it indexes: which sub-indexes exist, and which entities it covers. Deliberately small - the attribute, price and facet structures are stored apart precisely so this one is not rewritten when they change, which is why it is a poor proxy for the index footprint.
Everything built because an attribute is filterable, sortable, unique or part of a sortable compound.
Everything built to answer price-based filtering and ordering.
Everything built to resolve references between entities. Faceting is charged separately.
The facet index - what a facet summary is computed from. Charged apart from `REFERENCE_INDEX` because `faceted` and `indexed` are separate schema decisions.
The hierarchy index - the tree structure a hierarchical collection is queried through.
Everything built for the bucketed histogram indexes a REFERENCE SCHEMA declares - bucketed values, their range trees and cardinality gating. Named for the reference on purpose: the `attributeHistogram` and `priceHistogram` extra results are computed on the fly from the filter and price indexes and have no persisted storage part at all, so they never appear in a composition breakdown. Bytes here are the cost of the reference-schema histogram definitions read back by the `referenceHistogram` require constraint.
Schema records - the catalog schema and one entity schema per collection.
Header records the data store keeps to describe itself and its collections.
What a storage part fundamentally is - the coarse fold of `GrpcStoragePartGroup`, and the one a composition table uses when it wants three rows rather than fourteen. The three answer different questions: entity data shrinks only by storing less, an index shrinks by indexing less (a schema decision that loses no data), and metadata is what the store needs to describe itself and cannot be acted on at all.
Used in:
Default value, never sent by the server. Every reported storage-part type carries an explicit kind.
The entity's own persisted state - body, attributes, associated data, prices, references.
Structures the engine derived from entity data to answer queries. Every byte is reconstructible by a reindex and every byte was asked for by a schema flag.
Schema and header records - what the data store needs to describe itself.
How much of a data store one storage-part type occupies. Shared by the catalog-level and the collection-level storage composition, because the histogram has the same shape whichever data store it was read from.
Used in: ,
Simple class name of the storage part, e.g. `EntityBodyStoragePart`, `AttributesStoragePart`, `AssociatedDataStoragePart`. An OPEN set - it grows whenever the engine gains an index structure - so it is an identity to show, never one to classify by. Group by `group` instead.
Number of records of this type currently held (records).
Total size the records of this type occupy (bytes).
Which kind of data this storage-part type holds - what a composition table groups by. A CLOSED set: a new part type lands in an existing group, so a client that knows these values keeps rendering a correct table across engine versions.
The coarse fold of `group` - entity data, an index derived from it, or the store's own metadata. Sent rather than derived from `group` because a generated client enum carries no behaviour to derive it with; it is always the kind that `group` belongs to and can never contradict it.
The catalog-level `COMPONENT_STORAGE_SIZE` component - the catalog's disk footprint broken into the classes that have different remedies, because a single total tells a developer nothing: data they inserted, garbage awaiting compaction and time-travel history they could shorten by changing retention are three different problems. The total is measured, not derived - it is the sum of the actual lengths of every file in the catalog directory, so `sizeOnDiskInBytes` equals the sum of all the other fields *by construction*. Anything the engine does not track deliberately (a temporary file left by an interrupted compaction, a partial restore) lands in `unaccountedBytes` as a visible signal rather than silently disappearing from the report. Delivered even when the catalog is unusable: file lengths are readable whether or not the catalog loads. The in-memory-derived parts then read `0` and the bytes they would have accounted for surface in `unaccountedBytes`.
Used in:
Measured total - the sum of the lengths of every file in the catalog directory (bytes).
Active records across the catalog and all collection data stores (bytes).
Superseded records inside the current data stores - what compaction reclaims (bytes).
Retained write-ahead log files; `0` when time travel is disabled (bytes).
Superseded data files that are no longer current but not yet deleted (bytes). Not a time-travel artefact - such files occur in both modes, only the purge timing differs - but with time travel enabled they survive the whole history window, so this is where that cost shows up. Deleting them by hand is never the remedy.
The part of `awaitingDeletionBytes` still referenced by an open reader or writer (bytes). A value that stays high means a long-running session is pinning disk space.
The part of `awaitingDeletionBytes` that nothing blocks, waiting only on the purge mechanism (bytes).
The catalog bootstrap / version index file (bytes).
Everything present in the catalog directory that belongs to none of the classes above (bytes).
The part of `liveBytes` held by the catalog's OWN data store - schema, headers and catalog-level indexes - rather than by any collection's (bytes). Within one response the remainder is the sum over every open collection.
The part of `wasteBytes` held by the catalog's own data store (bytes).
Wrapper for representing an array of strings. Also used to carry a Character array — each element is then a single-character string; which Java array type applies is determined by the accompanying GrpcEvitaDataType (STRING_ARRAY vs CHARACTER_ARRAY).
Used in: ,
The individual string (or, for a character array, single-character) elements, in their original order.
Strip/offset-based pagination descriptor for a `GrpcDataChunk` - the alternative to `GrpcPaginatedList` used when the query's `require` block specifies a `strip()` requirement instead of `page()`.
Used in:
Maximum number of records returned in this strip.
Number of records skipped from the beginning of the result set before this strip starts. 0-indexed: an offset of 0 starts at the very first record - unlike `GrpcPaginatedList.pageNumber`, this is not a page number.
Area covered by the system CDC capture. Deliberately separate from GrpcChangeCaptureArea because the system stream has no SCHEMA/DATA semantics. The zero value SYSTEM_AREA_UNSPECIFIED encodes "no area set" / null on the domain side so proto3's default-value semantics do not collapse a null criterion into ENGINE. See issue #1151 for the rationale.
Used in:
Sentinel for an absent area — domain `null` round-trips through this value rather than collapsing into ENGINE because of proto3 default-value semantics.
Engine mutations (durable, WAL-replicated).
Host events (HostSystemEvent - non-replicable, live-tail-only).
State aggregates the possible states of a task into a simple enumeration.
Used in: ,
* Task is waiting in the queue to be executed.
* Task is currently running.
* Task has finished successfully.
* Task has failed.
* Task is waiting for precondition to be satisfied.
Record representing status of particular asynchronous task
Used in: , , , , , , , ,
Type of the task (shortName of the task) Available tasks: - "BackupTask": Task responsible for backing up the catalog data and WAL files into a ZIP file. - "RestoreTask": This task is used to restore a catalog from a ZIP file. - "JfrRecorderTask": Task is responsible for recording selected JFR events into an exportable file. - "MetricTask": Task that listens for JFR events and transforms them into Prometheus metrics.
Longer, human-readable name of the task
Unique identifier of this task instance; use it to reference this task in status lookups or cancellation requests.
Name of the catalog this task operates on. Unset for tasks that are not scoped to a single catalog (e.g. server-wide/system tasks).
Date and time when the task was issued for execution (queued to run). Unset while the task is still pending and has not yet been issued.
Date and time when the task started executing. Unset before execution begins.
Date and time when the task finished executing, successfully or with an error. Unset while the task is still running.
Coarse-grained lifecycle state of the task (queued, running, finished or failed), derived from the task's more detailed internal state.
Progress of the task (0-100)
String representation (`toString()`) of the task's configuration settings. Read back as an empty string if unset.
The task's result, once it has produced one. At most one of these is set; neither is set while the task has not finished or produced no result.
String representation (`toString()`) of the task's result object, used for any result other than a fetchable file.
The file produced by the task (e.g. a backup archive), available for fetching by `fileId`.
Public-safe error message if the task failed. Unset while the task is running or if it completed without error.
Capabilities available for this task instance (e.g. whether it can be manually started, cancelled, or must be explicitly stopped).
Date and time when this task status record was created; always set, and precedes `issued`.
Enum describes traits of a GrpcTask task.
Used in:
* Task can be manually started by the user.
* Task can be manually cancelled by the user.
* Task needs to be manually stopped by the user (otherwise it will run indefinitely).
Enum represents time flow direction for time-based filtering.
Used in:
Time flows forward - from past to future.
Time flows backward - from future to past.
This container holds information about single entity enrichment.
Used in:
The query operation associated with enrichment.
The primary key of the enriched record
This container holds information about single entity fetch.
Used in:
The query operation associated with entity fetch.
The primary key of the fetched record
This container holds a mutation and its metadata.
Used in:
The mutation operation; exactly one of the following is set.
The entity mutation operation.
The schema mutation operation.
Container for a query and its metadata.
Used in:
The shortened description of the query and its purpose
The query operation.
The total number of records calculated by the query.
The primary keys of the records returned by the query (in returned data chunk). I.e. number of records actually returned by the pagination requirement of the query.
The client labels associated with the query.
Record represents a CDC event that is sent to the subscriber if it matches to the request he made.
Used in: ,
The sequence order of the session (analogous to sessionId, but monotonic sequence based on location in the log).
The session id which the recording belongs to.
The order (sequence) of the traffic recording in the session. First record in the session has sequence ID 0 and represents the session start, additional records are numbered sequentially.
Total count of the records in the session. This number allows clients to determine whether the recordSessionOffset is the last record in the session (i.e. when recordSessionOffset = recordsInSession - 1, then it is the last record).
The type of the recording.
The time when the recording was created.
The duration of the operation in milliseconds.
The size of the data fetched from the permanent storage in bytes.
The number of objects fetched from the permanent storage.
The error message the operation this record represents finished with. If unset, the operation completed without error.
The body of the traffic recording, present only when body content was requested via the capture criteria's `content` field (`TRAFFIC_RECORDING_BODY`); entirely absent when only headers were requested (`TRAFFIC_RECORDING_HEADER`). When present, exactly one of the following members is set, matching this record's `type`.
Present when `type` is `TRAFFIC_RECORDING_MUTATION` - the entity or schema mutation that was executed.
Present when `type` is `TRAFFIC_RECORDING_QUERY` - the internal evitaDB query (evitaQL) that was executed.
Present when `type` is `TRAFFIC_RECORDING_ENRICHMENT` - the entity enrichment call that was executed.
Present when `type` is `TRAFFIC_RECORDING_FETCH` - the single entity fetch call that was executed.
Present when `type` is `TRAFFIC_RECORDING_SESSION_FINISH` - statistics collected over the closed session.
Present when `type` is `TRAFFIC_RECORDING_SESSION_START` - metadata about the newly opened session.
Present when `type` is `TRAFFIC_RECORDING_SOURCE_QUERY` - the raw, unparsed query as received from the client.
Present when `type` is `TRAFFIC_RECORDING_SOURCE_QUERY_STATISTICS` - statistics aggregated over all operations related to a single source query.
Record for the criteria of the capture request allowing to limit mutations to specific area of interest and its properties.
Used in: ,
Determines whether only basic information about the traffic recording is returned, or the actual event content as well (see the `body` oneof on `GrpcTrafficRecord`).
The lower time bound (inclusive) for returned traffic records. If unset, no time-based lower bound is applied.
The session sequence ID (see `GrpcTrafficRecord#sessionSequenceOrder`) from which the traffic recording should be returned (inclusive). If unset, no session-sequence lower bound is applied.
The record offset within the session identified by `sinceSessionSequenceId` from which the traffic recording should be returned (the offset is relative to the session sequence ID and starts from 0); allows continuing to fetch a session's traffic recording from the last fetched record when the session was not fully fetched in a previous call. If unset, records are returned from the start of the session.
The types of traffic recording to be returned. If empty, records of all types are returned.
The session IDs to limit the returned traffic recording to. If empty, records from all sessions are considered.
The minimum duration (milliseconds) the traffic recording operation must have taken to be returned. If unset, no minimum-duration filter is applied.
The minimum number of bytes the record must have fetched from the permanent storage to be returned. If unset, no minimum-size filter is applied.
The client labels the traffic recording must have (both name and value must match). If empty, no label filter is applied.
Enum to specify the depth of details sent in the traffic recording event.
Used in:
Only the header of the event is sent.
Entire traffic recording content is sent.
List of all possible traffic recording types.
Used in: ,
evitaDB session opened.
evitaDB session closed.
Query received via. API from the client - container contains original string of the client query. API might call multiple queries related to the same source query.
Query received via. API from the client is finalized and sent to the client. Container contains the final statistics aggregated over all operations related to the source query.
Internal evitaDB query (evitaQL) was executed.
Internal call to retrieve single evitaDB entity. Record is not created for entities fetched as a part of a query.
Internal call to enrich contents of the evitaDB entity.
Internal call to mutate the evitaDB entity or catalog schema.
This container holds information about the session close.
Used in:
The version of the catalog
The overall number of traffic records recorded for this session.
The overall number of queries executed in this session.
The overall number of entities fetched in this session (excluding the entities fetched by queries).
The overall number of mutations executed in this session.
The number of traffic records that were missed due to buffer overflow.
This container holds information about the session start.
Used in:
The version of the catalog that will be used for the entire session.
This container holds information about the source query.
Used in:
The unique identifier of the source query
unparsed, raw source query in particular format
The automatic labels associated with the query.
This container holds information about the source query statistics.
Used in:
The source query id
The number of records actually returned by the query, i.e. the size of the fetched data chunk after pagination.
The total number of records matching the query, before pagination is applied.
Structure that holds changes within a transaction.
Used in:
The number of catalog schema changes within the transaction.
The number of mutations within the transaction.
The size of the write-ahead log (WAL) in bytes for the transaction.
The collection of entity collection changes within the transaction.
This transaction mutation delimits mutations of one transaction from another. It contains data that allow to recognize the scope of the transaction and verify its integrity.
Used in: ,
Represents the unique identifier of a transaction.
Represents the next version the transaction transitions the state to.
Represents the number of mutations in this particular transaction.
Represents the size of the serialized transaction mutations that follow this mutation in bytes.
Represents the timestamp of the commit.
Structure that holds overview of a specific transaction.
Used in:
The version of the catalog that the transaction moved to.
The id of the transaction.
The commit timestamp of the transaction.
The timestamp when the transaction was processed.
The processing lag of the transaction in milliseconds (i.e. duration between commit timestamp and the real shared view incorporation).
The flag indicates whether point-in-time recovery to this version is possible.
The collection of changes within the transaction.
Contains set of all possible transaction phases each transaction goes through.
Used in:
All changes passed conflict resolution steps and are not in conflict with other transactions.
Changes are written to Write Ahead Log (WAL) and are safely persisted on disk. Client might rely on the fact that the changes will eventually be visible in the database.
Changes are visible in shared state of the database and are available to all newly created sessions.
Enum defines the two modes of traversing a hierarchy when using the `traverseByEntityProperty` ordering constraint.
Used in:
The depth-first traversal mode traverses the hierarchy in a depth-first manner, meaning it will explore as far as possible along each branch before backtracking.
The breadth-first traversal mode traverses the hierarchy in a breadth-first manner, meaning it will explore all the nodes at the present depth level before moving on to the nodes at the next depth level.
Request for updating the catalog schema.
Used as request type in: EvitaSessionService.UpdateAndFetchCatalogSchema, EvitaSessionService.UpdateCatalogSchema
Collection of local catalog schema mutations to be applied.
Request for updating the schema of an existing entity type.
Used as request type in: EvitaSessionService.UpdateAndFetchEntitySchema, EvitaSessionService.UpdateEntitySchema
Wrapper that holds the entity type and the collection of EntitySchemaMutations to be applied.
Mutation that upgrades a catalog's on-disk storage protocol from `fromProtocolVersion` to `toProtocolVersion`. Drives the state transitions `OUT_OF_DATE` → `BEING_UPGRADED` → prior operational state and serves as the WAL-backed record of the per-catalog lazy format upgrade.
Used in:
Name of the catalog whose storage protocol is being upgraded.
Storage protocol version currently present on disk (captured for observability).
Storage protocol version to upgrade to, typically the engine's current `STORAGE_PROTOCOL_VERSION` (captured for observability).
Upsert associatedData mutation will either update existing associatedData or create new one.
Used in:
Unique name of the associatedData. Case-sensitive. Distinguishes one associated data item from another within single entity instance.
Contains locale in case the associatedData is locale specific.
New value of this associated data. Data type is expected to be the same as in schema or must be explicitly set via `valueType`.
Upsert attribute mutation will either update existing attribute or create new one.
Used in: ,
Unique name of the attribute. Case-sensitive. Distinguishes one associated data item from another within single entity instance.
Contains locale in case the attribute is locale specific.
New value of this attribute. Data type is expected to be the same as in schema or must be explicitly set via `valueType`.
This mutation allows to create / update `price` of the entity.
Used in:
Contains identification of the price in the external systems. This id is expected to be used for the synchronization of the price in relation with the primary source of the prices. This id is used to uniquely find a price within same price list and currency and is mandatory.
Contains identification of the price list in the external system. Each price must reference a price list. Price list identification may refer to another Evita entity or may contain any external price list identification (for example id or unique name of the price list in the external system). Single entity is expected to have single price for the price list unless there is `validity` specified. In other words there is no sense to have multiple concurrently valid prices for the same entity that have roots in the same price list.
Identification of the currency. Three-letter form according to [ISO 4217](https://en.wikipedia.org/wiki/ISO_4217).
Some special products (such as master products, or product sets) may contain prices of all "subordinate" products so that the aggregating product can represent them in certain views on the product. In that case there is need to distinguish the projected prices of the subordinate product in the one that represents them. Inner record id must contain positive value.
Price without tax.
Tax rate percentage (i.e. for 19% it'll be 19.00)
Price with tax.
Date and time interval for which the price is valid (inclusive).
Controls whether price is subject to filtering / sorting logic, non-sellable prices will be fetched along with entity but won't be considered when evaluating search query. These prices may be used for "informational" prices such as reference price (the crossed out price often found on e-commerce sites as "usual price") but are not considered as the "selling" price. Deprecated since 2024.10 - RENAMED TO "indexed"
Controls whether price is subject to filtering / sorting logic, non-indexed prices will be fetched along with entity but won't be considered when evaluating search query. These prices may be used for "informational" prices such as reference price (the crossed out price often found on e-commerce sites as "usual price") but are not considered as the "selling" price.
Mutation is responsible for introducing a `GlobalAttributeSchema` into an `EvitaSession`.
Used in: ,
Name of the attribute the mutation is targeting.
Structure for representing UUID objects.
Used in: , , , , , , , , , , , , , , , , , , , , , , , ,
The most significant 64 bits of the UUID, as returned by `UUID#getMostSignificantBits()`.
The least significant 64 bits of the UUID, as returned by `UUID#getLeastSignificantBits()`.
Wrapper for representing an array of UUIDs.
Used in:
The individual UUID elements, in their original order.
The catalog-level `COMPONENT_VOLATILE_STATE` component - what is held in memory but not yet on disk, and what is being kept alive purely for readers that started long ago. `oldestRecordKeptTimestamp` is the one to watch: the multi-version history retained for still-open sessions is the part of the heap that grows silently.
Used in:
Size the data stores occupy including data not yet flushed (bytes).
Records written but not yet flushed to disk (records).
Size those records occupy (bytes).
Creation time of the oldest record kept alive for an open session. Unset when nothing is being retained.
The same state for the catalog's OWN data store alone - the slice of every figure above that belongs to no entity collection. Always set when this component is delivered.