couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Newson <>
Subject Re: deb versioned database dirs
Date Wed, 12 Sep 2012 09:38:43 GMT

From 1.0.0 onwards we promise to support forward migration of database and view files, we
shouldn't be introducing any breaking changes that prevent any future couchdb release from
reading .couch files from 1.0.0 or any release hence. The versioned database dir pattern must
have been useful in the past, but it's obsolete now. We could look to see what other db's
do when an administrator upgrades to a new version that also changes the on-disk format, especially
since we don't provide a downgrade path.

One thought is that we disable or remove the automatic upgrading to the new format and allow
administrators to do it electively. It's a fair amount of work, though. I would rather show
a warning for those upgrades that change disk_version that informs the administrator and recommends
taking a backup before proceeding.


On 12 Sep 2012, at 05:25, Randall Leeds wrote:

> 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.
> [0]

View raw message