| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
The value of source_seq is just what's been seen, not what's actually
been stored on the target. We expose through_seq now to show the actual
progress.
|
| |
|
|
|
| |
Further speedups to replication.js. Now runs in 32s on my machine vs.
the 1m45s it started at.
|
| |
|
|
|
|
|
|
|
| |
Attempting to compare the source and target update_seq values isn't
valid as any document modification on the source will permanently alter
the comparison. This changes things to just wait for the task's status
to update and reflect the source database's update sequence.
Locally this shortens the replication.js test by about 45s.
|
| |
|
|
|
|
|
| |
There was a race condition where we could end up grabbing repDoc1 before
the replicator manager got around to updating it. Local timespans had
this in the 19ms range. Rather than slap a timeout on it I've added a
call to a longpoll on the changes feed to wait for the update.
|
| |
|
|
|
|
|
| |
If you're running this using ./dev/run you need to use the -- to stop
option processing by ./dev/run like so:
./dev/run -- test/javascript/run --start path/to/file/start.js
|
| | |
|
| |
|
|
|
|
| |
Tweak hard coded assumptions about update_seq ordering for documents
posted to _bulk_updates. See the comment in replication.js for more
information.
|
| |
|
|
|
|
|
| |
The change to lager changed how w configure logging in CouchDB. We'll
need to figure out if we want to update things so that we can configure
lager from the INI files at which point we can either reenable this test
or remove it.
|
| | |
|
| |
|
|
|
|
| |
This is a short term fix to get lager to send its output to
stdout/stderr so that it is directed into the appropriate logs for
dev/run.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is moves a majority of the attachment representation
into the couch_att module. This serves to isolate the
current record to allow easier in-place upgrades as well as
a place to start collecting common attachment related
functionality.
The upgrades are handled lazily to allow rollbacks to older
code if the new attachment format has not yet been required
via storage of any of the new extended attributes supported
by the fetch/store APIs. There are some caveats to this in
that the extended attributes are not enforced by couch_att
at this time so it'd be quite easy to store garbage. As the
extent of attachment concerns becomes more stable, a set of
more permanent fetch_[field]/store_[field] functions may be
added to help enforce both field types as well as common
field names and defaults (all fields will default to
undefined except for those defaults present in the orignal
record definition, which carry over automatically).
Finally, while this patch does move a lot of code to
couch_att, it hasn't refined the interfaces much. These
changes will follow in later patches to improve and
simplify the organization of attachment code. This
includes the addition of more unit tests which currently
only cover some portions of the attachment functionality
related to upgrades and field fetching & storage.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We have three results that can happen when merging a path into a
revision tree:
* We can extend a branch which replaces a leaf
* We can create a new branch which results in a new leaf
* We can land on an existing internal node
The first result (new_leaf) means that there is no conflict in the
update operation. The second (new_branch) means we branched a revision
path which means the operation introduces a conflict. The third
(internal_node) means that the merge was the result of an edit that
has already been applied to this document.
For the third case we have a subtle special case in that if we have
deleted the document and want to recreate it into the same initial
state we need to give the new state a different revision. The current
code follows the edit path and extends the first deleted leaf it
finds.
BugzID: 25150
Conflicts:
apps/couch/src/couch_key_tree.erl
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |\ |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| | |
Otherwise this causes include conflict issues with other Erlang
applications which were installed system-wide by system package manager.
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The EventSource connection can get stuck (in TCP half-open state*) and there's no way
for the client to detect that. This commit changes the way heartbeat is sent, instead of
sending a newline character, it sends an empty event of type heartbeat:
event: heartbeat
data:
This event doesn't have an id: field, so the client will retain its latest Last-Event-ID state.
This doesn't change the expectations of clients that used EventSource till now, because they
subscribe to the 'message' event type. To get the 'heartbeat' events a client will need to
explicitly subscribe to it:
source.addEventListener('heartbeat', function () { /* cancel a timer that would otherwise reconnect the source */ });
* this can happen when you suspend your laptop, on flaky internet connection, ADSL reconnect,
bad wifi signals, bad routers etc. Pretty often in a typical internet usage nowadays.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Passing unexpected values to auth fields can result in server
issues. Notably, setting "iterations" to a string will cause an
infinite loop as the comparison 'when Iteration > Iterations' will
never evaluate to true.
The latest validate_doc_update prevents user docs with this problem
and administrators can deploy that check themselves (and only
administrators can edit design documents).
A server administrator can also insist on lower and upper bounds for
iteration count to reject weakly protected passwords and
resource-hungry passwords respectively.
COUCHDB-2221
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This removes client-side password crypto from the JavaScript tests.
In some JavaScript tests, it has been assumed that SHA-1 is used for the
password hash in user docs. Those tests should, however, not rely on
implementation details of the user authentication hash function, as it
isn't the goal of those tests to check these. Furthermore, this causes
problems when a password scheme is changed, or a new one is introduced.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
We now upgrade user docs to the new PBKDF2 password scheme on successful
authentication if the password hash is still from the old days where we
only used plain SHA-1 for hashing salted passwords.
Closes COUCHDB-1780.
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
