Hi EXPERTS,
I am experiencing an inconsistency when using Configuration Hub to back up and restore JDBC applications that have merging enabled. After restoring a deleted source from a Configuration Hub draft, the merging configuration structure changes, leading to aggregation failures.
Steps to Reproduce
-
Perform a backup of a JDBC application (with merging enabled) using Configuration Hub.
-
Delete the original source from the system.
-
Restore the source using the saved Draft in Configuration Hub.
-
Observation: Compare the merging configuration before backup and after restoration.
Configuration Comparison
Stage 1. Original State
Expected Behavior / State: Merging configuration is correctly defined as below
Group.mergeRows:false and Group.indexColumns:[F_ID_MASTER] .
Actual Result: Works as expected; aggregations succeed.
Stage 2. Backup JSON
**Expected Behavior / State :**The JSON file exported via Config Hub should match the API/XML definition.
Group.mergeRows:false and Group.indexColumns:[F_ID_MASTER]
Actual Result: The JSON reflects the correct configuration.
Stage 3. Post-Restore
Expected Behavior / State: Configuration should be identical to Stage 1. but changed as below
Group.mergeRows:true and Group.indexColumns:[F_ID_SLAVE] (THIS IS WRONG)
Actual Result: Configuration is altered (Group.mergeRows:true and Group.indexColumns:[F_ID_SLAVE]
), causing aggregation to fail.
Impact
-
Aggregation Failure: The restored source cannot process data due to the malformed merging logic.
-
Manual Overhead: Currently requires manual intervention via API to fix the configuration, which is not scalable for environments with numerous JDBC applications.
Can any one please help me on the below?
-
Is this a known limitation of Configuration Hub when handling the mergeRows or indexColumn attributes in JDBC?
-
Why does the Draft restoration process modify the JSON structure specifically for merging configurations?
cheers,
VJ