Confusing copyDatabase API when used with encryptionKey
Description
The current definition of copy database API states
/// Copies a canned databaes from the given path to a new database with the given name and
/// the configuration. The new database will be created at the directory specified in the
/// configuration. Without given the database configuration, the default configuration that
/// is equivalent to setting all properties in the configuration to nil will be used.
///
/// - Parameters:
/// - path: The source database path.
/// - name: The name of the new database to be created.
/// - config: The database configuration for the new database name.
Requirement: Copy (unencrypted) database and encrypt the target copy
Expected: Specify encryptionKey in config and expect it to work
Observed: Arcane exception is thrown. Turns out that encryptionKey thats specified in config is expected is for decrypting source database
There are several related issues here
1) API spec is not aligned. If config is for target, there cannot not be expectation of providing decryption key for source db in that config. Seems like we should have a different option for specifying key for encrypted source database
2) Error log is non-informative. I don't have it at hand but you can test it and you will see that it provides no indication of the mistake
3) API documentation needs to be updated to describe what should be expected (and what one should do if they want to encrypt target database)
Pasin Suriyentrakorn September 21, 2021 at 12:05 AM
I have created 1 Doc issue, 3 API docs issues, and 1 Lite-Core issue for fixing error message in the log. Please see the linked issues.
Pasin Suriyentrakorn September 20, 2021 at 11:59 PM
2) Error log is non-informative. I don't have it at hand but you can test it and you will see that it provides no indication of the mistake
Here is the current log and yes, it could be improved.
Pasin Suriyentrakorn September 20, 2021 at 11:24 PM
Edited
1) API spec is not aligned. If config is for target, there cannot not be expectation of providing decryption key for source db in that config. Seems like we should have a different option for specifying key for encrypted source database
The behavior is expected. The method is for copying the database (It doesn't recreate the database and copy data over) as a result the encryptionKey specified in the config is the encryption key for both original database and the copied database (no change).
The encryption key in the config is used for opening and not for changing. We have a dedicated method for changing the encryption key. Therefore, if the encryption key needs to be changed or needs to be enabled (from no encryption), the changeEncryptionKey(key) method will need to be explicitly called after.
Fixed
Pinned fields
Click on the next to a field label to start pinning.
The current definition of copy database API states
/// Copies a canned databaes from the given path to a new database with the given name and
/// the configuration. The new database will be created at the directory specified in the
/// configuration. Without given the database configuration, the default configuration that
/// is equivalent to setting all properties in the configuration to nil will be used.
///
/// - Parameters:
/// - path: The source database path.
/// - name: The name of the new database to be created.
/// - config: The database configuration for the new database name.
Requirement: Copy (unencrypted) database and encrypt the target copy
Expected: Specify encryptionKey in config and expect it to work
Observed: Arcane exception is thrown. Turns out that encryptionKey thats specified in config is expected is for decrypting source database
There are several related issues here
1) API spec is not aligned. If config is for target, there cannot not be expectation of providing decryption key for source db in that config. Seems like we should have a different option for specifying key for encrypted source database
2) Error log is non-informative. I don't have it at hand but you can test it and you will see that it provides no indication of the mistake
3) API documentation needs to be updated to describe what should be expected (and what one should do if they want to encrypt target database)