Weekly CouchDB meeting – (summary)

BigCouch Merge : windsor-merge is essentially complete [update Aug 28: by the time this post was published, it has just been completed], this work will be merged to the master branches of all affected repositories in the next days. After the merge to master, help with testing will be needed.

: windsor-merge is essentially complete [update Aug 28: by the time this post was published, it has just been completed], this work will be merged to the master branches of all affected repositories in the next days. After the merge to master, help with testing will be needed. Apache CouchDB 1.6.1 : release candidate 4 (rc.4) is being tested at the moment and looks good so far.

: release candidate 4 (rc.4) is being tested at the moment and looks good so far. CouchDB 2.0 scope : CouchDB 2.0 is likely to be the result of merges of code from BigCouch and rcouch’s view changes (so far, this is only a prediction, it hasn’t been decided yet) additional, larger changes will be worked on later

: Fauxton: a lot of work has been done lately and will be included soon

a lot of work has been done lately and will be included soon HTTP refactoring: ongoing discussion which HTTP server to move forward with. Pros and Cons of the options will be written down so they can be discussed on the mailing list and voted on eventually.

Major Discussions

Vote (ongoing): Release of Apache CouchDB 1.6.1-rc.4 (will be released as Apache CouchDB 1.6.1) (see thread)

The release candidate is out. Please help us test it out! You’ll find details on the testing procedure here.

Best Practices on Replication (see thread)

Question: A CouchDB user asked about the best setup to assure consistency.

Answer: Eventual consistency is ensured by CouchDB’s design. Users just have to take care of resolving conflicts manually (eventually correcting the CouchDB assumption on which document version prevails).

Recommended rev_limit value (see thread)

Question: A user asked if reducing the rev_limit value had a positive impact on performance, and, if so, which was the recommended value.

Answer: Low values are not recommendable, because during replication that would mean users are assuming that their nodes are replicating nicely all the time, without network interruptions or limitations. If rev_limit is low and, for any reason, users miss to replicate a number of revisions higher than the limit, they’ll run into trouble. If users are constantly writing the same document many times, the rev_limit should be high. If the writes operations spread around a large number of documents, the revision numbers won’t grow so quickly and thus rev_limit can be lowered.

Deleted documents being replaced by previous versions (see thread)

Setup: CouchDB 1.5.0 with master-master replication.

Question: sometimes a document has multiple revisions stored,

and when deleting the most current one, a previous one replaces it

and becomes available.

Answers:

What’s happening here is that the document is conflicted. That is, there are multiple ‘latest’ revisions to choose from. In this situation, CouchDB chooses one of them to present to the user when they do GET /dbname/docid. When they then delete that revision, they are promoting one of the others.

The common way to introduce conflicts is to edit the same document at multiple locations and then replicate, which would appear to be the setup in this specific case.

It is only non-latest (the CouchDB-term is “non-leaf”) revisions that are removed by compaction, CouchDB preserves all of the latest revisions (as we do not know which edit or edits you want to keep).

CouchDB does not resolve conflicts, it preserves them until you resolve them (e.g. by deleting them).

If i user is updating the same document at two different sites, and then replicating them, they will introduce conflicts. This is something they need to account for in their application. If user A updates document sample on site 1 and user B updates document sample on site 2 then, after replication, both sites will present either user A or user B’s update, and the other is a losing their revision (preserved but hidden).

Rewriting the CouchDB HTTP Layer (see thread)

A discussion on rewriting the CouchDB HTTP layer has been started this week, you can find the initial email with detailed suggestions and notes here. The general idea behind the rewrite is i.a. to make the code easier to test, remove unnecessary code duplication, organise the code even better and make it easier to write plugins – thus, to make it easier for developers to contribute.

The discussion is still ongoing.

Releases in the CouchDB Universe

Opinions and other News in the CouchDB Universe

Use Cases, Questions and Answers

no public answer yet:

For more new questions and answers about CouchDB, see these search results.

Get involved!

If you want to get into working on CouchDB:

We have an infinite number of open contributor positions on CouchDB. Submit a pull request and join the project!

on CouchDB. Submit a pull request and join the project! Do you want to help moving the CouchDB docs translation forward? We’d love to have you in our L10n team! See our current status and languages we’d like to provide CouchDB docs in on this page. If you’d like to help, don’t hesitate to contact the L10n mailing list on l10n@couchdb.apache.org or ping Andy Wenk (awenkhh on IRC).

We’d be happy to have you!

Events

Job opportunities for people with CouchDB skills

Time to relax!

“Like an over-stretched hard-drive when we take no time off we get pretty cranky and slow. To reboot I’ve had to really think hard about what I love doing and built this into my weekends.” – Take a break: how I learned to relax and reboot

“Being nice is incredibly overrated. I have no desire to be nice, and I think a culture of “nice” is counter to a culture of consent and boundaries. I prefer to be kind and empathetic – these are things to aspire to.” – On the importance of boundaries and consent

… and also in the news