On this page
Merger configuration
Configure how Trazadera Golden chooses values for a mastered record with constant, date, number, script, or stable random precedence.
A merger-weight resource controls which contributing values become the
mastered record after records are resolved as the same subject.
Configure precedence
This is sample-customer-merger from the
Aurelia Utilities sample:
{
"type": "merger-weight",
"_id": "sample-customer-merger",
"description": "The most recently contracted record becomes the golden one",
"dataset": "sample-customer",
"mergeType": "DATE",
"mergeSort": "HIGHEST_WEIGHT",
"key": "contractDate"
}
A DATE column a merger sorts on needs a parse pattern in its dataset.
Set validation: "PARSER" and source: "yyyy-MM-dd" on the column. Without
it the column has no usable formatter, and the entity fails validation with
“Column contractDate is not ready: define a valid formatter.”
The resource defines one precedence strategy. It does not contain a weights
array.
Merge types
| Type | Precedence input |
|---|---|
DATE | A date column selected by key |
NUMBER | A numeric column selected by key |
CONSTANT | Whether key contains the configured constant |
SCRIPT | A reviewed script that returns a precedence value |
RANDOM | Stable selection when no business signal is preferred |
mergeSort is HIGHEST_WEIGHT or LOWEST_WEIGHT. Read it together with the
merge type: for a DATE key, highest normally prefers the newest value and
lowest the oldest.
Golden builds the result by applying the configured precedence to record values. Multiple-value columns preserve values from contributors rather than using the same single-value choice. Validate nested and array fields explicitly because their desired business outcome can differ from scalar precedence.
Choose a precedence key
In the sample’s Ana case, the clean CRM record has a 2024 contract date and
its misspelled CRM duplicate has a 2022 date. Sorting on contractDate with
HIGHEST_WEIGHT gives the newer record precedence. This does not mean that
every candidate group represents one person: review the identity decision
before applying a merger.
Reversing the sort gives older values precedence even when those values are worse. A successful merge confirms that the operation completed; inspect the survivor to verify that the chosen precedence matches the business policy.
Choose a precedence key that reflects the approved source-authority policy, then verify the surviving values.
Verify the result
Build a test group whose records deliberately disagree on the precedence key and on several business values. Confirm the mastered result matches policy and that contributing records remain inspectable through the supported record view.
Re-test when source semantics change. A recency rule is only reliable if the configured date continues to mean what the merger assumes.