Release Date: 06-Sep-19
This is a minor feature and bug fix release. As always, existing CopyStorm configuration files are backwards compatible.
|11-Sep-19||Fix a bug in meta data storage that was not explicit about using UTF8 for a byte to string conversion.|
|18-Sep-19||Winter’20 Issues with “reified columns”. Replace all SELECT MAX() code with a database specific technique.|
|23-Oct-19||Last Summer’19 updates. Fix issue with ContentVersion not cleaning up temp files on skipped records.|
Support SFDX Username and Aliases for Salesforce Credentials
A new type of credential, SFDX Username or Alias, is supported. This means that if an SFDX Alias is provided to CopyStorm all the information needed to connect to Salesforce will extract from SFDX. A particularly interesting use case for SFDX authentication is to use a batch version of CopyStorm/Restore to seed a new scratch org immediately after a scratch org is created.
Add UNKNOWN_EXCEPTION Analysis Tool
On rare occasions Salesforce will report an UNKNOWN_EXCEPTION. This means that something has gone wrong in their infrastructure. From experience we have learned that this type of exception is often caused by the query of a particular field on a specific record and have published a procedure for identifying the culprit and reducing the problem SOQL to something small enough for Salesforce support to respond. This release builds the analysis procedure into the CopyStorm software making the identification and creation of a problem SOQL query a simple task.
Detect Near Divide by Zero Formula Columns
Occasionally we see formula columns that produce numbers like 99.32e25 (an obvious mistake). On databases without a generic numeric column this can cause a numeric overflow problem on record inserts. We have solved the problem by identifying problem formula column values and storing a null value instead. Of course, this new feature can be turned off.
Improve Ability to Estimate How Long a Backup Will Take
A new column, Last Timestamp, in the backup progress table contains the most recent record timestamp encountered for each table. Using this value a user can determine how many days, months, years, etc. of data still needs to be backed up for a table. For example, if the Last Timestamp displayed for the Attachment table is 2019-01-01 11:45:23 then Attachments modified after this time still need to be backed up.
Backup New Metadata Types
A number of new metadata types are now backed up, including: DuplicateRule, Community.*, Lightning.*, SiteDotCom, etc.
Refactor PostgreSQL Field History Retention Policy Enforcement Code
The Field History Retention Policy code for PostgreSQL was refactored to avoid massive database transactions when large numbers of field history records needed to be deleted.