CouchDB 1.1.0

http://couchdb.apache.org/downloads.html

by franze • 15 years ago

72 22 15 years ago

couchdb.apache.org

JoachimSchipper• 15 years ago

Can someone explain what's so important about this release?

evangineer2• 15 years ago

The biggies I've been personally waiting to see land in this release are:

* Added OS Process module to manage daemons outside of CouchDB.

* Added HTTP Proxy handler for more scalable externals.

What these effectively mean is that you can write CouchDB handlers in the language of your choice as long as they speak http. You can get the full details from the author of the above patches here:

http://davispj.com/2010/09/26/new-couchdb-externals-api.html

This makes possible things like LivelyCouch, integrating node.js with Couch:

http://www.livelycouch.org/

js4all• 15 years ago

I didn't know about livelycouch. It seems to be a great idea. Thanks for mentioning it.

evangineer2• 15 years ago

A bunch of the other changes are about making CouchDB more suitable as a public-facing web server, hence the SSL support & improved ETag support for example.

rdtsc• 15 years ago

Here are some:

* Added _replicator database to manage replications.

It used to be that if a continuous replication was launched but the server was re-started that replication task was lost. Now it will continue where it left off.

* Added support for HTTP range requests for attachments.

Just looking at the unit-test for this commit, you can apparently specify a range of bytes out of an attachment and fetch only that.

    var xhr = CouchDB.request("GET", "/test_suite_db/bin_doc/foo.txt", {
 	headers: {"Range": "bytes=10-15"}
 	});

* Added stale=update_after query option that triggers a view update after returning a stale=ok response.

Before, if stale=ok was passed to a view then you'd just get back stale view data and (I am guessing) a view update wasn't triggered. Normally a view update is triggerred the frist time the view is accessed after documents have been updated. However that could take a while for the views to regenerate. Now with stale=update, stale data is returned but an view update is _also_ triggerred in the background.

* Added configuration option for TCP_NODELAY aka “Nagle”.

Should help for situations where you'd want to trade some throughput for latency. Your packets will be sent out sooner, they will be smaller, but there will probably be lots more of them. See here for more :

  http://en.wikipedia.org/wiki/Nagle%27s_algorithm

e2718282• 15 years ago

The CouchBase version has been at 1.1.0 for a while (since March 24):

http://www.couchbase.org/wiki/display/membase/Releases

Does anyone know if theirs was an early release of 1.1? Or are their version numbers out of sync with the Apache versions?

daleharvey3• 15 years ago

Couchbase releases are not in sync with CouchDB releases, the Couchbase server is based on CouchDB 1.0.1, the reason their versions arent aligned as Couchbase releases are not Apache CouchDB releases

robterrell• 15 years ago

I've been using the CouchBase release since before they became CouchBase. I haven't closely followed the whole CouchOne/Membase merger. Is there any reason to switch to the official Apache release?

e2718282• 15 years ago

Thanks Dale, this is good to know. Any plans to update Couchbase server to be based on CouchDB 1.1? I know the _replicator DB would be a particularly nice feature to have.

perezd2• 15 years ago

This is a huge release. Replicator was effectively re-written, much faster internals, HTTPS support is native. These features are warmly welcomed! Excited to see this now integrated into BigCouch!

daleharvey3• 15 years ago

The new replicator isnt in the 1.1 release, it is in trunk and likely to be in the next release

perezd2• 15 years ago

This is not true. read the release notes.

deskamess• 15 years ago

In the older (v0.9) docs they recommended pull replications over push . Is this still the case? (http://wiki.apache.org/couchdb/Replication)

We would like to push support related data from a customer db (inaccessible from the outside) into an external server.

rb2k_3• 15 years ago

I wish CouchDB would implement internal compaction. I'd love to use CouchDB and Elastic Search with the CouchDB River plugin. This would give me a nice REST infrastructure with a schemaless store (couchDB) and the ability to do complex queries in real time (elastic search).

Sadly my data is too write/update-heavy and just keeps on growing and growing. This means that I'll have to use compaction if I don't want to run out of space sooner or later. Starting compaction will kill performance over several hours and depending on the amount of written data might not even be able to finish :(

jchrisa• 15 years ago

We are working on auto compaction. The Couchbase alpha already supports it. This should help, but it will help even more on a cluster as each shard can be compacted independently.

rb2k_3• 15 years ago

does "auto compaction" mean that the compaction process is just automatically triggered?

CouchDB 1.1.0

Related Stories