I think it’s difficult to make a call when 3.0 is still so new. The case for deprecation here is basically less code to maintain, right? It’s not like a user of partitioned databases is causing pain for an FDB-based CouchDB; if anything, there’s a second-order benefit because the partitioning discourages hot spots from forming in the (range-partitioned) FDB keyspace.
Cheers, Adam > On Apr 20, 2020, at 11:51 PM, Kyle Snavely <kjsnav...@gmail.com> wrote: > > My two cents is the same. Let's allow 3.* users migrate to 4.* without > needing to e.g. change the PQ part of their application and remove the PQ > endpoints in 5.0. > > Best, > Kyle > > On Mon, Apr 20, 2020, 4:16 PM Ilya Khlopotov <iil...@apache.org> wrote: > >> Given that it unlikely that there are too many people using it and it is >> being noop in FDB world. I think we should deprecate and remove _partition >> endpoint. >> >> On 2020/04/20 21:04:58, Robert Samuel Newson <rnew...@apache.org> wrote: >>> Hi All, >>> >>> I'd like to get views on whether we should preserve the _partition >> endpoints in CouchDB 4.0 or remove them. In CouchDB 4.0 all _view and _find >> queries will automatically benefit from the same performance boost that the >> "partitioned database" feature brings, by virtue of FoundationDB. >>> >>> If we're preserving it, are we also deprecating it (so it's gone in 5.0)? >>> >>> If we're ditching it, what will the endpoint return instead (404 Not >> Found, 410 Gone?) >>> >>> Thoughts welcome. >>> >>> B. >>
