The newly created document not made to the database file even the log suggested otherwise

Hi there,

I have encountered a very weird bug when use couchbase lite 1.4.1 in my android native application.

I write a document to the database, everything seems fine.

Here how I create document:

    final Document document = mDatabase.getDocument(id);
    try {
        Log.d(TAG, "DB+" + id);
    } catch (DBException e) {
        Log.e(TAG, "Exception during create", e);

01-24 08:49:24.490 24867-24949/ V/Database: PUT _id=local/INK::e85a63af-36d6-410b-9985-4c3f0aced52a, _rev=1-9e665b532c24b79766d92c3751c7080c (allowConflict=false)
01-24 08:49:24.491 24867-24949/ V/Database: ModelSynchronizer Begin transaction (level 0)
01-24 08:49:24.495 24867-24949/ V/Database: ModelSynchronizer Committing transaction (level 0)
01-24 08:49:24.496 24867-24949/ V/CBLite: —> Added: {local/INK::e85a63af-36d6-410b-9985-4c3f0aced52a #2-dfddbbfa99de7e8d2f59b98631f780e4 @6} as seq 6

However, before and after the transaction, the size of the db file (db.sqlite3) doesn’t change, and I pulled the db file and opened it in the DB Browser, the document with that id isn’t there.

Another observation is: it appears the data were written to the database file by batch (> 16k). Basically, if I keep create document, it will write to the database at certain point, and it is not by time interval, but by the number of documents - which means no matter how long I wait, it won’t happen.

Please help, is there anything that could cause this to happen?

Another weird thing is when the database is initially created. It is blank with no tables, no documents. And the db.sqlite3 file is 1k size. It feels the data were in memory rather than persistence.

Apparently, it is an issue with DB Browser, I have to open another file and then open the target db file, otherwise it isn’t reloading it.

1 Like

The database consists of not just the .sqlite3 file but also the _shm and _wal files; you can’t just copy one of them. In particular, the _wal file is a Write-Ahead Log, which stores recent updates in order to speed up writes. The records eventually get copied into the actual .sqlite3 file and removed from the WAL.

You shouldn’t need to copy the database to browse it. Just open DB Browser on the same database file. SQLite has no problem with multiple processes accessing the same db.