Re: [DISCUSS] _changes feed on database partitions

2020-05-14 Thread Robert Samuel Newson
Per-shard will not mean anything from 4.0 onward so at least I was not thinking of that. per-partition has meaning from 3.0 onward as partitions are user defined. B. > On 14 May 2020, at 22:11, Joan Touzet wrote: > > > > On 2020-05-13 10:07 a.m., Robert Samuel Newson wrote: >> Hi, >> Yes,

Re: [DISCUSS] _changes feed on database partitions

2020-05-14 Thread Joan Touzet
On 2020-05-13 10:07 a.m., Robert Samuel Newson wrote: Hi, Yes, I think this would be a good addition for 3.0. I think we didn't add it before because of concerns of accidental misuse (attempting to replicate with it but forgetting a range, etc)? This was definitely a concern, but it

Re: [DISCUSS] _changes feed on database partitions

2020-05-13 Thread Robert Samuel Newson
Hi, Yes, I think this would be a good addition for 3.0. I think we didn't add it before because of concerns of accidental misuse (attempting to replicate with it but forgetting a range, etc)? Whatever the reasons, I think exposing the per-partition _changes feed exactly as you've described

[DISCUSS] _changes feed on database partitions

2020-05-12 Thread Adam Kocoloski
Hi all, When we introduced partitioned databases in 3.0 we declined to add a partition-specific _changes endpoint, because we didn’t have a prebuilt index that could support it. It sounds like the lack of that endpoint is a bit of a drag. I wanted to start this thread to consider adding it.