Thanks Jens! On Tuesday, July 8, 2014 5:56:06 PM UTC-7, Jens Alfke wrote: > > > On Jul 8, 2014, at 5:31 PM, Len Kawell <[email protected] <javascript:>> > wrote: > > > (1) A previous post in this forum suggested that compact runs on the > replicator's thread, but from what I can see it seems to run synchronously > on the thread it's been invoked from (e.g., main thread). Is that the case? > > Yes, it runs on the thread you invoke it on. > > > (2) Does compact "lock" the database from other access and threads? > > Yes. > > > (3) Is there any benefit or problem with invoking compact on another > thread using either CBLManager -backgroundTellDatabaseNamed:to: or by using > a CBLManager copy to make another CBLDatabase instance in another thread? > > Well, it will let your main thread do other stuff during the compaction. > But if it makes any CBL calls it’ll block till the compaction finishes, > because the database is locked. > > > (4) Is compact "safe" to run automatically without the user's > involvement? For example, if the user powers off their device while compact > is in-progress, should the database be OK? Or should I display a warning > message to try to avoid that? > > Well, you don’t want the app to get terminated by the OS in the middle of > a compact. The database shouldn’t be corrupted by this (it’s supposed to > be impossible to corrupt a SQLite database these days) but I don’t know > what state it’ll be in afterwards. > > > (5) Are there any replication issues to be aware of with compact? For > example, does it play nice with the replicator task itself? Will pending, > non-replicated updates get replicated OK after the compact if it's done > while offline? > > The only effect it’ll have on replication is that it will prune some very > old revisions. That won’t affect anything that hasn’t been replicated > already. > > > (6) Are there any built-in database statistics or metadata that I could > use to trigger compact? Or should my app maintain its own document and > attachment update and deletion counts somewhere? Or maybe just do a > compaction periodically? > > I would just do it periodically. > > > (7) What sort of performance should we expect from compact? Is there any > way to give the user a progress UI or possibly an estimate of the time it > will take? > > Not really; most of it is just a small number of SQLite commands that each > can take a long time to finish. > > > For example, I found running it the first time on a 7.5GB test database > it took about 2 minutes on an iPad Air: > > Yow, that’s really big. Compaction is definitely going to take a long time > on a database that size — it should be run more regularly. > > > 2014-07-08 11:17:47.278 App[6015:60b] Starting database compact... > > 11:19:40.907| CBLDatabase: Deleting JSON of old revisions... > > 11:19:41.728| Deleting old attachments... > > 11:19:42.131| Deleted 75 attachments > > 11:19:42.131| Flushing SQLite WAL... > > 11:19:42.414| Vacuuming SQLite database... > > 11:19:49.736| Closing and re-opening database... > > 11:19:49.740| ...Finished database compaction. > > 2014-07-08 11:19:49.739 App[6015:60b] Database compact done - error = > (null) > > It looks like pruning old revisions is what’s taking most of the time > (almost two minutes.) I don’t know if that query could be made more > efficient. Mostly I’d recommend running the compaction more often so > there’s less to clean up. > > (For what it’s worth, ForestDB, which we’re going to switch to from SQLite > in the future, runs compaction automatically in the background and it > doesn’t block access to the database. It’s much more like CouchDB > compaction.) > > —Jens
-- You received this message because you are subscribed to the Google Groups "Couchbase Mobile" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/mobile-couchbase/dec1987b-d358-40f0-8ee4-0ff47bf36f4f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
