| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
COUCHDB-1304
|
|
|
|
|
| |
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 9f2398faef3936a844caffbaf3eef8675383ccfd which
switched couch_log to use disk_log. Unfortunately that module performs
positioned writes which prevents the usual logrotation strategy from
working correctly.
|
| |
|
| |
|
|
|
|
|
|
|
| |
Some users will incrementally reload a single code module into a running
couchdb instance and wish to run the js tests again. This allows
test/javascript/run to execute outside of make check by using an env
variable COUCHDB_NO_START.
|
|
|
|
| |
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 55d2c9e390cf06a76ff6715a60b85f8f4ca26f97,
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.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
If the updater collects 2 updates for the same document
where the first deletes it and the second creates it, it
would send a conflict error to the client of the create
request. This wouldn't happen if the 2 requests were
collected in 2 different batches by the updater.
Closes COUCHDB-188
|
|
|
|
|
|
| |
The conflicts option belongs to couch_db:open_doc/3 and not
to couch_doc:to_json_obj/2. Also added the deleted_conflicts
option.
|
|
|
|
| |
Patch by Dave Cottlehuber.
|
|
|
|
|
|
|
| |
On windows we install binaries directly into $(prefix)/bin rather than
a local bin directory hidden away in the erlang module. Therefore, when
building this way, don't try to create a symbolic link into the final
location since the final location has the output binary already.
|
|
|
|
|
|
|
| |
As of 32fb9f8e0416910a2431227b5fbdeef93ccd94bc this should no longer be
necessary.
This reverts commit 2d90a1249dea1d02d46266d52a0d269f0a33dbb0.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the ini configuration parameter `use_users_db` (section
`couch_httpd_oauth`) is set to true, OAuth credentials can
be stored in user documents (system database _users) instead.
The credentials are stored in a top level propery of user
documents named `oauth`. Example:
{
"_id": "org.couchdb.user:joe",
"type": "user",
"name": "joe",
"password_sha": "fe95df1ca59a9b567bdca5cbaf8412abd6e06121",
"salt": "4e170ffeb6f34daecfd814dfb4001a73"
"roles": ["foo", "bar"],
"oauth": {
"consumer_keys": {
"consumerKey1": "key1Secret",
"consumerKey2": "key2Secret"
},
"tokens": {
"token1": "token1Secret",
"token2": "token2Secret"
}
}
}
Closes COUCHDB-1238.
|
|
|
|
|
|
|
| |
The test now includes attachments to verify that the
incremental attachment replication code path succeeds
when there are many leaf revisions of a document with
attachments.
|
|
|
|
|
|
|
|
|
|
| |
This removes the need for c4f6ff9c6cf5512546d5799f05dd445a4da979b3
which was made in response to -ansi coming from icu-config on my
system. Instead, it's more sensible to use the preprocessor flags from
icu-config which provides the -I header locations and -D definitions
but doesn't add a bunch of excessive warning flags or ansi conformance.
This reverts commit c4f6ff9c6cf5512546d5799f05dd445a4da979b3.
|
|
|
|
| |
main patch from jan, reviewed & updated by me.
|
| |
|