Schema API design

The article contains basic concepts around evitaDB entity schemas and an example of how to define them from Java code.

All schema classes are designed as immutable and follow similar rules as entities - including naming conventions and versioning. They don't follow the soft-removal approach, though. The changes in the schema affect the database structure and once applied, the previous schema of the catalog is no longer available.

Evolution

evitaDB is designed to be schema-full with automatic evolution support. One can start without a schema and immediately create new entities in the collection without reasoning about the structure. evitaDB works in "auto evolution" mode and builds schemas along the way. The existing schemas are still validated on each entity insertion/update - you will not be allowed to store same attribute the first time as a number type and next time as a string. First usage will set up the attribute schema, which will have to be respected from that moment on.

Default schema implicitly creates all attributes as nullable, filterable and non-array data types as sortable. This means the client is immediately able to filter / sort almost by anything, but the database itself will consume a lot of resources.

evitaDB can operate in strict schema mode when the structure is defined up-front, and then sealed so that all entities must strictly correspond to the predefined schema and violations will generate exceptions. This behaviour needs to be specified at the moment of collection of the creation.

There are several partial lax modes between the strict and the lax mode - see

Schema definition example

A schema can be programmatically defined this way:

Author: Ing. Jan Novotný

Date updated: 15.12.2022

Documentation Source