Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.activeviam.com/llms.txt

Use this file to discover all available pages before exploring further.

The datastore configurator object contains methods for the following actions:
ActionDetails
Field customizationsInserting, appending, updating and removing fields from a datastore
Reference mapping customizationsAdding or removing pairs of fields
Store configuration customisationsPartitioning, chunk sizes, duplicate key within transaction behaviour, NUMA selector, etc.
Adding new storesAs implementations of IStoreDescription, whether mutable or created through the core API
Adding new referencesAs implementations of IReferenceDescription
Creating instancesInstances 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 categoryWhen defined
Default storeWhen instantiating the MutableStoreDescriptionBuilder object.
Custom globalWhen using the ConfigurationConstants.ALL_STORES constant as the store name. These options will apply to all customizable stores for the given schema. The IConfigurableSchema.GLOBAL constant allows for a configuration to be applied for multiple schemas at once.
Multi-store custom configurationWhen passing in a list of store names. These options will apply to all the stores in the list.
Individual custom configurationWhen 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.