As per mailing list discussion on enabling the syncing of _security objects this builds upon the previous commits to enable the agreed upon strategy of giving a revision tree to the _security object. The old API is maintained with identical in the normal single node case. Though it is also now possible to update the _local/_security doc directly using the normal HTTP document and _bulk_docs API's to edit the doc directly. This document is special cased like _design docs to disallow non-admins from editing it.
If a user uploads a two _local docs with the same docid in a _bulk_docs request the updater will insert multiple entries into the local docs btree. This patch avoids that by throwing an error if a user attempts it. This is an old bug that I caught and just added a fix for. I split it out as its own patch to point out that its a bug fix that differs from the old behvior.
There are a number of cases that _local docs might need to be merged between nodes. One motivating case is for clusters that might wish to move _local docs across nodes to maintain replication checkpoints with external CouchDB instances. The previous _local docs strategy of a single linear sequence breaks down in this situation. This new behavior should be indistinguishable from the previous behavior assuming clients did not try and introspect the _rev value for _local documents. It should be impossible for normal HTTP clients to introduce different behavior than previously existed because there's no support for non-linear updates at the HTTP level. This update is merely and internal refactoring for special cases like clusters.
* Refactor couch_key_tree:merge/3 and helper functions * Rewrite couch_key_tree tests for new merge/3 functionality * Remove merging logic from couch_db_udpater:merge_rev_trees/6 * Introduce couch_doc:merge/3 to handling revision merging This patch does not change any outwardly visible behavior of CouchDB. The old revision merging code was split across a couple functions with important merging logic mixed into couch_db_udpater:merge_rev_trees/6. This is important because couch_db_updater:merge_rev_trees/6 is also the same code responsible for handling update_seq updates. This patch factors out the revision merging and conflict detection into couch_doc:merge/3 with the left over update_seq logic remaining in couch_db_udpater:merge_rev_trees/6. This approach is being taken so that we can reuse the revision merging for other parts of CouchDB, notably the _local docs btree.
Don't restart https if we start httpd and vice-versa.
These tweaks make the test pass on slower machines/environments.
Since we're using the x-couchdb-requested-path header to track the requested path we should expose it in the request object we pass to the view server. Currently this object has a `requested_path` key which has the pre-vhost path. However, when there is no virtual host it will have the post-rewrite path. With this change it always presents the path which was requested by the client, whether or not virtual hosts were matched. This should make the lives of app authors easier by giving them a reliable source for constructing relative paths and redirects that works with and without virtual hosts.
My last commit broke because the header detection wasn't using the JS_CPPFLAGS that includes the search paths. Fix is simply to move that variable assignment to before the header check.
Randall's last patch to only test for JSOPTION_ANONFUNFIX ended up reordering the test before the headers were located. This ran into errors in version detection. This patch reorders the header location as well as adds a few more default search paths when no --with-js-include option is specified to account for newer SpiderMonkeys that puth their headers into $PREFIX/include/js.
On conflict, keep using the current revision tree. Issue noticed by Paul Davis. Thanks.
This happens if the ddoc_updated event is received after a client opens the new view group or if a design document is updated several times in a row and there are still clients streaming views from 2 or more view groups that match old versions of the design document. This relates to COUCHDB-1309
This reverts commit 9f2398f which switched couch_log to use disk_log. Unfortunately that module performs positioned writes which prevents the usual logrotation strategy from working correctly.
The NIF API in OTP R15B introduced the enif_is_number function.
Change waitForSuccess to catch errors in the sync request that's used to hand control back to the JS engine. Then, use waitForSuccess to see if CouchDB has started and remove the 1 second sleep before the tests start.
This partially reverts 55d2c9e, adding only a Content-Type of application/json to post requests against _revs_diff.
This restores the previous default behaviour.
This appears to expose a bug in Chrome for an edge case. There's a test that sends "Range: bytes=0-29" for an item that is one byte shorter than the requested range. Curl, Firefox and Safari correctly returns; Content-Range: bytes 0-28/29 Content-Length: 29 Whereas Safari erroneously gets this; Content-Range: bytes 0-29/29 Content-Length: 30 So, this test will fail on Chrome until a) Chrome is fixed or b) someone points out that I'm wrong about the Chrome bug.
Some requests made by the replicator were missing a Content-Type header. By default now all requests have a Content-Type of application/json.
Even non-continuous _changes requests, particularly filtered ones, can cause long periods of inactivity.