evitaDB - Fast e-commerce database
logo
page-background

Behavioral require containers

Special behavioural require constraint containers are used to define a require constraint scope.

In Scope

argument:enum(LIVE|ARCHIVED)

mandatory enum argument representing the scope to which the require constraints in the second and subsequent arguments are applied

requireConstraint:any+

one or more mandatory require conditions, combined by a logical link, used to require entities only in a specific scope

The inScope (
) require container is used to restrict require conditions so that they only apply to a specific scope.

The evitaDB query engine is strict about indexes and does not allow you to require or sort on data (attributes, references, etc.) for which no index has been prepared in advance (it tries to avoid situations where a full scan would degrade query performance). Scopes, on the other hand, allows us to get rid of unnecessary indexes when we know we will not need them (archived data is not expected to be queried as extensively as live data) and free up some resources for more important tasks.

The scope require constraint allows us to query entities in both scopes at once, which would be impossible if we couldn't tell which require constraint to apply to which scope. The inScope container is designed to handle this situation.
It's obvious that the inScope container is not necessary if we are only querying entities in one scope. However, if you do use it in this case, it must match the scope of the query. If you use the inScope container with the LIVE scope, but the query is executed in the ARCHIVED scope, the engine will return an error.
For example, in our demo dataset we haven't created facet or hierarchy indexes for archived entities. The price information is also not indexed. So if you tried to calculate facet summary or histogram information for entities in the archive scope, you'd get an error from the query engine. If you are querying entities in multiple scopes, you should use the inScope container and limit these calculations to only those scopes where the indexes are prepared:

As you can see, the result contains calculations for the data that the engine can calculate.

Similar inScope containers are available for filter constraints and ordering constraints with the same purpose and meaning.
Some require constraints allow results from multiple facets to be combined. For example, facet summary, attribute histogram and price histogram can be computed for both live and archived entities if the appropriate indices are available.

Author: Ing. Jan Novotný

Date updated: 29.11.2024

Documentation Source