android-fhir
android-fhir copied to clipboard
google
Ability to Dump Application's Database
Is your feature request related to a problem? Please describe.
We have experienced sync issues due to malformed resources, caused by some references not properly set such as missing the resource type before the reference. Resources with such issues fail to sync since the referenced resources are not found on the server.
Identifying the cause of the failing sync has proven hard, especially when we are unable to reproduce the issue on our staging environment.
Describe the solution you'd like
To make troubleshooting possible for cases that are hard to reproduce, we would like a copy of the application's database to be downloadable to device storage for further investigations.
The dumped database file should be encrypted with a password that is defined by the app calling the database download SDK API.
Describe alternatives you've considered
- Our implementation for a quick release to unblock an issue involved duplicating class com.google.android.fhir.db.impl.DatabaseEncryptionKeyProvider.kt in FHIRCore to allow us access the encrypted database.
- The encrypted password is then decrypted and copied to a plaintext database file. The plaintext file is zipped with a password and is availed for saving to file or sharing
Additional context
Add any other context or screenshots about the feature request here.
Would you like to work on the issue?
Please state if this issue should be assigned to you or who you think could help to solve this issue.
@jingtang10 please feel free to review the PR On OpenSRP. I think we want to move that kind of functionality to the SDK
@jingtang10 We would like to revisit this issue and have the feature in the SDK. Please review the issue and share your thoughts.
Can you please discuss this issue in today's developer call? @Simon Njoroge @Aditya Khajuria @Madhuram Jajoo
We are happy to add this ability. Along with this there should also be a way for application to modify data before dump - so a plugin which application can implement and register.
Can you tell us how you are doing this in the PR linked above. Would you work on this @qiarie ? Thanks.
@qiarie We also wanted to understand the use-case more. Questions are around difference between staging and prod environment - and the possibility of replicating the scenario to troubleshoot the sync issue in prod environment ? For example, one could upload all the logs to troubleshoot, no ?
Hello @MJ1998.
We are happy to add this ability. Along with this there should also be a way for application to modify data before dump - so a plugin which application can implement and register.
This is noted. Do you mind giving more information on there should also be a way for application to modify data before dump - so a plugin which application can implement and register.
Can you tell us how you are doing this in the PR linked above. Would you work on this @qiarie ? Thanks.
I will check with my team and share an update
@MJ1998
@qiarie We also wanted to understand the use-case more. Questions are around difference between staging and prod environment - and the possibility of replicating the scenario to troubleshoot the sync issue in prod environment ? For example, one could upload all the logs to troubleshoot, no ?
In our current use case and implementation, a user is able to initiate a raw database download to the file system.
For debug versions, the database is unencrypted and is saved as is to the file system. For release versions, the app's database is encrypted. An empty database file is created. The encrypted database is read and its contents copied to the empty DB file.
In both cases, the database is zipped and a ZIP password set.
After internal discussions and careful evaluation, we've decided not to implement the database dump feature at this time. This decision aligns with our core principle of maintaining a secure, encrypted database environment. Additionally, we believe this feature may become less relevant as our sync capabilities mature.