Utilize CloudSQLite block sharing locally to efficiently store multiple versions of an iModel on a local disk

[khanaffan]

The concept is that Cloud SQLite’s block-sharing capability can significantly reduce disk space usage, especially when it’s beneficial to maintain two or more versions of an iModel.

For instance, version 1 of an iModel might be 10GB. If I need a version with a few changesets, the file size would still be around 10GB. Instead of keeping two 10GB copies on disk, we can use block sharing. This way, most blocks that are the same between the two files are stored once, and only the blocks that differ are stored separately

The use cases are

• Version Comparison
• Updating Channel Data when there are schema changes
• Upgrading to a Major Schema Version
• Changeset Rebasing
  • This approach avoids rolling back changes during a rebase. Instead, we create another version of the iModel and apply local changes to it.

Note: This is unrelated to the cloud; the source blocks and manifest are stored on disk. BeSQLite’s cloud SQLite should offer a method to initialize a disk-based cloud SQLite that reads and writes blocks to a disk directory. Nothing written to each file alters the block cache; all changes remain in the briefcase locally, and only the changeset is pushed out.

[kabentley]

Nothing written to each file alters the block cache

The way this would work is to first create a "local container" (i.e. a container with no cloud storage). Then, the rest of the CloudSqlite api would apply unchanged: you'd create a CloudCache, attach the (local) Container, and then use the CloudSqlite api to "copy" the iModel so you'd have multiple versions in the same container. All changes would be to blocks in the CloudCache, but the manifest would just be local and never "uploaded" anywhere. The write lock on the container would be implied.