Github user davisp commented on the issue:
https://github.com/apache/couchdb-couch/pull/241
Updated to use define's for batch sizes and fixed the changes/doc count
mixup.
For the {merge_start, forward}, thats only there for completeness. It felt
a bit weird to not include that event even though I don't necessarily need it
for this work.
Updates during the second phase happen here:
https://github.com/apache/couchdb-couch/pull/241/files#diff-f6f654ab26b490bab95be6f502c49d89R1376
This is a bit subtle but it seemed like the best I could do without
starting to modify the on-disk contents of files which I like to avoid when at
all possible.
Its a bit funky but without starting to store the total number of rows in
emsort the best approach I had was to guess with the input being the total
number of changes processed in this run and then in the first phase of the
merge sort just count how many rows we have. Once that first pass is over we
can calculate the total number of rows that will be copied and then just update
progress in the normal fashion. Its a bit awkward but that emsort_cb kind of
switches modes once it sees that the first phase has ended and then its purely
just listening for row_copy events.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
