desktopcouch should compact its databases

[Guillermo Gonzalez]

Using bindwood I got a 2.6GB database, see Bug #427622
After compacting the DB the size is: 0.6MB

[Chad Miller (cmiller)]

The Ubuntu team will not stand for unnecessary disc usage. We have a service daemon that runs while d-c is running, and it currently manages replication. There's no reason it can't also clean up the databases occasionally.

[Chad Miller (cmiller)]

Compacting is a good idea, but the example rationale is strange.

That bug#427622 is marked as invalid at present.

[Stuart Langridge (sil)]

Bug 427622 is invalid because Bindwood no longer has the problem that caused it to create a huge database. There is nothing stopping other applications using desktopcouch from making the same mistake, though (repeatedly writing the same data to a document, which creates extra revisions and balloons the size of the DB, almost all of which is recovered by compacting), which is why we should guard against that.

[Elliot Murphy (statik)]

Marked the bindwood bug task as invalid. If it's easier, compacting desktopcouch at startup rather than with a cron job would be fine.

[Jason Gerard DeRose (jderose)]

I think having an option for desktopcouch to automatically compact databases periodically might be nice, but for many applications (ahem, dmedia), the application can do a better job of deciding when compaction is needed, when doing the compaction wont affect user experience.

So if this feature is implemented, I'd really want an easy way for an app to opt-out of the auto-compaction (maybe through something similar to excluded_names).

I'm not thrilled about the idea of having some (or all) the databases automatically compact when deskcouch first starts. The desktopcouch startup is already a bit sluggish, and compacting the databases could cause a lot of IO at an inopportune time.

In some ways I think educating app developers about compaction might be a better solution. My two cents. :)