How Do CopyStorm Views Work?
The Salesforce API presents all SObjects (Account,Contact, etc.) as tables to the outside world even though quite a number of SObjects are really subsets/views of other SObjects. The most common example is Salesforce feed tables — there are dozens of feed tables (AccountFeed, ContactFeed, etc.) that are simply views of the table that contains all feeds: FeedItem.
- The AccountFeed table is really a view on the base table FeedItem.
- SELECT * FROM FeedItem WHERE parentId IS an Account Record.
There are also cases where the Salesforce API does not support a direct query on an SObject but the SObject can be constructed from other SObjects.
- The ActivityHistory table is a union of the Event and Task SObjects but cannot be queried directly using SOQL.
There are other issues of this kind, but lets get to the important part. When Database Views are enabled in CopyStorm, then CopyStorm will use views in the target database rather than copying a table. This can lead to much faster backups for each table that can be represented as a view.
How to Enable Database Views
Database Views are enabled by default in CopyStorm and when enabled:
- If a Salesforce table does not exist in the target database and can be represented as a view, then CopyStorm will create it as a view.
- If a Salesforce table already exists in the target database, then CopyStorm will not re-create it as a view but will continue to treat it as a table.
If Database Views are disabled in CopyStorm:
- Database Views will not be created for new tables.
- If a Database View already exists in the target database, then CopyStorm will not change it.
The toggle that enables/disables Database Views is found in the Database Schema configuration section of the CopyStorm Configuration tab.
Implementation Details
This section is for anyone wanting to know exactly how the logic for determining whether a Database View should be used works.