Hi Jan,
Just to simplify it as much as possible we have a view like:
function (doc) {
emit(doc._local_seq, null);
}
In CouchDB 1.x _local_seq is global for the entire database and as far as we
ever noticed we'd never have a duplicate value for a single db. What we are
doing is syncing all documents from that view and then starting the _changes
feed from the last _local_seq we got.
In CouchDB 2.x _local_seq seems to be local to the database/shard as they are
all integer values and even then we have duplicates because I'm presuming each
shard has it's own _local_seq. What we'd need is the cluster aware seq that you
pass back to _changes for this to work.
Cheers,
Robert
> On 8/01/2017, at 7:43 AM, Jan Lehnardt <[email protected]> wrote:
>
> I know we fixed this for _all_docs:
> https://issues.apache.org/jira/browse/COUCHDB-2849
>
> Didn’t this make it into regular views as well?
>
> Robert, can you show an example of what you are doing in 1.x and what that
> returns for 2.x?
>
> Best
> Jan
> --
>
>> On 7 Jan 2017, at 19:32, Robert Payne <[email protected]> wrote:
>>
>> Hey All,
>>
>> Would anyone still by chance have an idea on this? Or a adequate alternative
>> that is performant?
>>
>> Cheers,
>> Robert
>>
>>> On 19/12/2016, at 5:07 PM, Robert Payne <[email protected]> wrote:
>>>
>>> Hey All,
>>>
>>> In CouchDB 1.x we used a view with the "local_seq" option and then used
>>> emitted _local_seq's to determine where to kick off a change feed starting
>>> point. If there any way to emit a cluster aware local seq in CouchDB 2.0? I
>>> can't seem to find any way to get the node/shard suffixed sequence when
>>> using a view.
>>>
>>> Cheers,
>>> Robert
>>
>
> --
> Professional Support for Apache CouchDB:
> https://neighbourhood.ie/couchdb-support/
>
