Best practices for calling CBLDatabase compact?


#1

When is the best practice for calling compact? And Would it happen if it is never called? I’m looking at some doc sync issues and I tracked it down to something that might related to calling compact. This is my current scenario:

  • App calls compact() everytime it goes into the background.
  • If a documented just got updated through a live query for a db that is also replicating with the SynchGateway and I put the app in the background (compact gets called) and then I opened the view that displays the document detail again, the document displays the previous document version and it is not until the replication finishes again that the document is updated. Although in this specific case (coming back from the background after calling compact) the doc replication takes a lot longer (20 secs aprox) vs opening the document when compact() is not called (2sec aprox)

#2

ForestDB databases don’t need to be compacted except to clean up leftover attachment files. The ForestDB engine itself does the compaction in the background itself, as needed.

Calling compact when the app is backgrounded is reasonable. You don’t need to do it all the time, though. Since the amount of work is proportional to how many revisions have been added, you can use the database’s lastSequence property to track that, and compact maybe every 1000 sequences or something similar.

The view update issue you describe sounds like a side effect of compaction being synchronous. (And it doesn’t matter if you try to do it on a background thread; since compaction holds a write-lock on the SQLite database, nothing else can access the DB until it completes.)


#3

I just updated the app to use 1.2.1 a few weeks ago but I think I need to add some migration code to move to ForestDB so I believe this db is still sqllite. I didn;t know about the lastSequenceNumber property, it looks like I’d need to keep track of the previous lastSequenceNumber so I can calculate the delta when the app goes into the background correct? I tried to use CBReplicator (push) pendingDocumentIds.count as an alternative so I don’t have to add the logic to keep track of the previous sequence but that actually returns 0 even though I see the sequence number increase if for example I make a document update.

To your last point, what it is happening is that the app offers a way to update a document in a view and users normally close the app right after that (it is part of their workflow), so we are missing some updates that sometimes never make it to the server.


#4

I’d need to keep track of the previous lastSequenceNumber so I can calculate the delta when the app goes into the background correct?

Correct.

we are missing some updates that sometimes never make it to the server.

You could try deferring the compaction until after the push replication goes idle. (You’ll need to start a background session with iOS to do this, so it’ll let you keep running a while after going to the background.)