Keeping It Closed

However, even if you were to opt out of WAL, it is important that your database be closed when we are making a backup or exporting the data. SQLite will know nothing about this backup/export operation. If part of your code is performing database operations while another part of your code is making a copy of the database file, you will wind up with a corrupted database copy. This is not unique to SQLite: making a copy of a file while that file is being written to is asking for trouble.

In principle, this is not too hard to manage:

• Before making the copy of the database, call close() on the RoomDatabase
• Make the copy
• Before trying to work with the database again, re-open it using a RoomDatabase.Builder

This makes a repository a bit more complicated, as now it will need to be able to close and open databases as needed. Plus, your repository will be your primary “line of defense” against bugs. For example, suppose that you have a WorkManager scheduled task to synchronize your app with a Web service. If that task gets executed while your backup is being made, you do not want to re-open the database at that time. Somehow, the Worker will need to find out that the database is unavailable, so it can reschedule that work.

The sample app, being a simple book sample, does not get into how to manage this, as the details will vary widely by app.