When performing XML imports using the ImportSetUtil Script Include, the sys_update_xml table is being updated, even if no structural changes are made.
The following output log was traced in a London instance:
Script completed in scope global: script
Script execution history and recovery available here
Operation Table Row Count
insert sys_update_version 2
insert sys_update_xml 2
update sys_db_object 1
insert sys_user 1
insert cmn_notif_device 1
Upgrading table: sys_user
Replication is not enabled on table: sys_user, not queueing replication table change special db event
sys_domain_path field already exists in sys_user
Background message, type:info, message: Primary email device created for Marty Grinstead.Example
Slow business rule 'Create primary email device' on sys_user:Marty Grinstead.Example, time was: 0:00:00.101
This produced two rows in the sys_update_xml table, with the following values:
1. Execute the following script from Scripts - Background:
var xml = "<import>";
xml += "<sys_user>";
xml += "<user_name>marty.grinstead.example</user_name>";
xml += "<email>firstname.lastname@example.org</email>";
xml += "<first_name>Marty</first_name>";
xml += "<last_name>Grinstead.Example</last_name>";
xml += "</sys_user>";
xml += "</import>";
var xmlDoc = new XMLDocument(xml);
var importSetUtil = new ImportSetUtil();
importSetUtil.loadFromXML("/import/sys_user/*", xmlDoc, "sys_user");
2. Check the sys_update_xml table and notice the two new rows generated.
3. If testing multiple times, make sure the value for the user_name is unique.
After carefully considering the severity and frequency of the issue, and the cost and risk of attempting a fix, it has been decided to not address this issue in any current or near future releases. We do not make this decision lightly, and we apologize for any inconvenience.
Within the ImportSetUtil script include there is logic which checks for existing column names in a table and removes them from the schema changes hashmap. There is no check to determine whether or not the schema changes hashmap is empty or not before executing the update call on GlideTableCreator.
The workaround is to check the size of the hashmap prior to executing the update call which ends up creating the extra rows, as follows:
NOTE: Updating an OOB script include will result in the inability to automatically update the specific script include during further instance upgrades.