I have two datasets to compare: an original table and a revised table. I want to pass them through the UpdateDetector to track Updates, Inserts, and Deletes. The two tables are linked by a shared primary key attribute, and I want to track changes that may exist in another attribute; however, the original table has an extra attribute, ExtraID, which does not exist in the revised table. For features that exit the Updated port, this ExtraID loses its value. How do I retain the values in ExtraID and prevent them from exiting the UpdateDetector as NULL?
Page 1 / 1
Features exiting the Updated port of the UpdateDetector exist in both Original and Revised tables, but with some differences. Since the Revised features are the ones output, the UpdateDetector has no access to the Original ExtraID, and does not know it should retain the attribute.
One workaround that will rejoin the dropped ExtraID after the UpdateDetector involves the FeatureMerger:
Using a FeatureMerger, features from the Original can be routed to the Supplier port, while features exiting the Updated port in the UpdateDetector can be routed to the Requester port. Joining on the KeyID will line up both the Original and Updated features, and the ExtraID attribute is ‘supplied’ to the Updated features. The Merged port will have the desired output: the Updated features and their attributes, plus the original ExtraID that was not present in the Revised table.
