So replicating with batch size 500 means that you have no events and then
suddenly 500 events synchronously all identical except for the docs written
field.

One key issue is that only the 500th event is actually actually accurate as
it is describing the state of things right now,  the previous 499 events
are giving out of date information and would not do what you expected if
you tried to cancel the replication after hearing one.

A way to think about doing event once per batch is that it is listing
changes to the target database and since the updates happen in batches each
batch of updates is a change
On Apr 23, 2014 5:21 PM, "Dale Harvey" <notifications@github.com> wrote:

> In lib/replicate.js:
>
> >        }
> >        result.last_seq = last_seq = currentBatch.seq;
> > -      utils.call(opts.onChange, null, result);
> > +      currentBatch.docs.forEach(function () {
> > +        result.docs_written++;
> > +        returnValue.emit('change', utils.clone(result));
>
> I am not sure about making that change either, changes may group multiple
> changes into a single document, but you still always get at least one
> change per document, its a huge bonus for the changes and the replication
> api to be symetrical, I dont see much wrong with 'flooding' the client
> side, if it needs to debounce changes to update the UI it can easily do
> that whereas if we group the changes we lose functionality
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/pouchdb/pouchdb/pull/1963/files#r11924543>
> .
>