Your use case may ask for keeping previous record versions when updates come in. For example when a customer record changes the name or the delivery address.
Here are the options you have using SearchCluster.
Index latest version only
This is the default, and means record versioning is not active. The last write to a record is the version that is kept, indexed, and returned from the store. Every previous version is discarded.
Your application may still keep record versions on your side. These could be stored in a relational database and made available to back-office employees in an administration interface. Or written to logs for an audit system.
Fully managed full record version
Every update to a record automatically stores a new version. Each version has an incremental record version number, and a timestamp.
Searching the Index may now be performed on current, historical, or both record versions.
The whole record with all record versions is returned for a search match, with detailed information about how the record versions matched (unless a filter is applied).
Strategies exist for how many record versions to keep:
- Limitation by number: keep the latest n record versions, for example 10.
- Limitation by date: don’t keep record versions older than a defined time, for example 3 years.
- Keep initial: option to always keep the first record version.
- Combination thereof
Self managed data versioning
Your application may implement its own record versioning logic, assemble a custom record in JSON format, and store that in your SearchCluster Index.
As a simple example, to keep previous email addresses, instead of using a simple field of type email you could use a list with a complex object containing a “last-seen” date for this value:
[{“emai”:email, “last-seen”: timestamp}]
<- Back to SearchCluster page.