Customising schemas using the configurator
The datastore configurator object contains methods for the following actions:
| Action | Details |
|---|---|
| Field customisations | Inserting, appending, updating and removing fields from a datastore |
| Reference mapping customisations | Adding or removing pairs of fields |
| Store configuration customisations | Partitioning, chunk sizes, duplicate key within transaction behaviour, NUMA selector, etc. |
| Adding new stores | As implementations of IStoreDescription, whether mutable or created through the core API |
| Adding new references | As implementations of IReferenceDescription |
| Creating instances | Instances of MutableStoreDescriptionBuilder , MutableReferenceDescriptionBuilder, and DatastoreSchemaDescription |
Configuration options can be split into the following categories, depending on the parameters used on the configurator.addConfiguration() methods:
| Configuration category | When defined |
|---|---|
| Default store | When instantiating the MutableStoreDescriptionBuilder object. |
| Custom global | When using the ConfigurationConstants.ALL_STORES constant as the store name. These options will apply to all customisable stores for the given schema. The IConfigurableSchema.GLOBAL constant allows for a configuration to be applied for multiple schemas at once. |
| Multi-store custom configuration | When passing in a list of store names. These options will apply to all the stores in the list. |
| Individual custom configuration | When using a unique schema and store name. |
Most store configuration options will follow a standard order of precedence (custom configuration for the store, custom global configuration, default store configuration), except for:
- Custom indexes: as multiple secondary indexes can be created for a store, the indexing calls are keyed by the input fields.
- Partitioning: all partitioning calls that accept one or more fields as inputs are keyed by those fields.
- Individual properties: the calls are keyed by the property name, so for any given property name, the order of preference will be respected. However properties defined by default will be used unless overridden.
The order of precedence does not differentiate between configuration options defined as part of multi-store or individual custom configurations. If configuration options are defined multiple times for the same stores, the ordering will be chronological.