incubator-couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Randall Leeds <>
Subject Re: deb versioned database dirs
Date Wed, 12 Sep 2012 04:25:35 GMT
On Sun, Sep 9, 2012 at 6:40 AM, Noah Slater <> wrote:
> Randall,
> Sorry for the very late reply (doing some long overdue email sprints).

Absolutely no worries. I've been doing a bit of the same myself. And
if you hadn't noticed, I haven't been hacking on couch much in the
last several months, sadly.

> What did you do about this in the end?

So far, my hacking has resulted in a package that alerts the user
(with a menu in the standard debian way) that they will need to
migrate the database files by hand after the upgrade. It then installs
CouchDB with /var/lib/couchdb as the database directory (rather than
/var/lib/couchdb/X.Y.Z). This package is in my PPA[0].

> I was the one who designed that scheme for Debian, so I can, at least, let
> you know the thinking behind it.
> I was concerned about an update to CouchDB breaking, or corrupting, old
> data. So, new package versions, obviously, install a fresh CouchDB, and it
> is up to you to port the data across.

That's totally clear. It's what I had guessed and I think it was the
right decision, for sure, at that time.

> Now, CouchDB is a lot more stable than it used to be, but we do, still,
> have breaking changes from time to time.
> How would those be handled by your package?
> (Or were you just installing the package, and not hacking on it, in which
> case, should we file a bug downstream?)

My thinking was that the common case these days in not breaking
changes, or at least breaking changes for which the software manages
upgrades on compaction and reads the old format.

With your feedback, and other devs, I'd like to know what our approach
should be. Should we continue to version the database directory at
all? Should we use major versions only (/var/lib/couchdb/{1,2}.x)?
Should we keep the old scheme?

The problem with always requiring a manual migration is that CouchDB
may be updated and then restarted without human intervention.
Suddenly, then, it appears to have no data! *If* we make a commitment
to support and upgrade database files in place, at least through a
single major version, then this problem can be avoided for many
upgrades. For example, Ubuntu could include our package verbatim in
the repos and know that they can ship security updates that only
increment the revision and users can install CouchDB on Ubuntu server
and trust the system to perform security updates without their
database disappearing suddenly.

I/we can do this any way we please, we just need to decide and justify
our decision.

Right now, I think I'd lean towards major version directories, or
perhaps instead disabling the init service via a flag in
/etc/default/couchdb on major version updates to force user
intervention only when necessary.

I'd love your thoughts.


View raw message