Customizing Record Storage
The redefined Corteza record storage now enables you to customize the way records are stored under the hood. Customizing record storage enables you to easily integrate external data as if it was created through Corteza, offload datasets to dedicated databases, or larger datasets to specialized data centres*.
|
To store records into a different connection, you’ll need to create it first. |
By default, Corteza stores all records (along with their values) into a single table, which should suffice for most basic use-cases. If your use case doesn’t require storing records in dedicated storage, feel free to skip this section.
Configuration
The record storage configuration options are available in the module edit page under the data store tab.
Connection
Basic connection parameters define what connection Corteza should use when storing the module’s records and where in the connection the data should be stored — such as what table or collection.
|
Changing the connection will reset the sensitivity level configuration on the module and fields if the sensitivity level is incompatible with the new connection. Refer to privacy settings to learn more about sensitivity levels. |
The database connection specifies what connection Corteza should use when handling the module’s records. By default, Corteza uses the primary connection. |
|||||
The collection or database table name specifies where the module’s records are stored inside the connection.
For some scenarios, Corteza can create the appropriate structures if they don’t already exist in the connection (such as a new table in an RDBMS database).
You can use the following placeholders:
|
Module Field Mapping
The module field mapping and encoding parameters specify which module fields should be stored and how they should be stored. Refer to the field encoding codecs section for details on the available value encoding codecs.
The map module field checkbox allows you to choose whether Corteza should store the module field’s values or not. If the checkbox is unchecked, Corteza will drop the values. Generally, you’ll want to store all of the module fields. If a field is no longer needed, you should remove it from the module definition. 
|
|
The encoding codec defines what coded Corteza should use when dealing with the field’s values. Refer to the field encoding codecs section for details. 
|
|
The codec configuration provides the required configuration parameters to the selected encoding codec. Refer to the field encoding codecs section for details. 
|
System Fields
The system module field mapping and encoding parameters allow you to specify which module fields should be stored and how they should be stored. Refer to the field encoding codecs section for details on the available value encoding codecs.
|
System fields, for the most part, provide metadata about the record. If needed, you can omit specific system fields from being stored. Omitting system fields can come in handy when connecting to existing databases whose structure doesn’t define all supported system fields. |
The map module field checkbox allows you to choose whether Corteza should store the module field’s values or not. If the checkbox is unchecked, Corteza will drop the values. Generally, you’ll want to store all of the system module fields, but you can omit the ones your custom schema does not support.
|
|||
The encoding codec defines what coded Corteza should use when dealing with the field’s values. Refer to the field encoding codecs section for details.
|
|||
The codec configuration provides the required configuration parameters to the selected encoding codec. Refer to the field encoding codecs section for details.
|
Field Encoding Codecs
The field encoding codec defines how the record value for the corresponding field should be stored and retrieved later. The available encoding codecs are listed in the table below with an explanation, configuration, and use cases.
The JSON field codec encodes the record value into a JSON object. The location of the JSON object (relative to the connection’s storage, such as the table column) is defined by the identifier provided alongside the encoding codec definition.
The encoding codec is useful when you wish to retrieve values from JSON objects.
|
|||||||||
The alias field codec encodes the record value as a stand-alone value under a custom identifier. The location (relative to the connection’s storage, such as the table column) is defined by the identifier provided alongside the encoding codec definition. The encoding codec is useful when you retrieve values from a dedicated location that can have a different identifier to the module field, such as a table column or collection attribute. |
|||||||||
The column field codec encodes the record value as a stand-alone value using the same identifier as the module field. The location (relative to the connection’s storage, such as the table column) is defined by the module field’s name.
The encoding codec is useful when you wish to retrieve values from a dedicated location with the same identifier as the module field, such as a table column or collection attribute. |
