Hi, Good points on both sides of this. One thing we can hopefully get agreement on is the ?partitioned=true flag on creation and, deeper, the lack of distinction between the two "types" of database going forward?
B. > On 21 Apr 2020, at 18:51, Garren Smith <gar...@apache.org> wrote: > > I'm on the fence when it comes to removing it. In terms of the original > plan of making querying faster by querying fewer shards that obviously > isn't needed. But I think it does create a nice mental model/design pattern > when building an application in CouchDB. Splitting your data into > partitions that contain similar documents makes sense. And once we on FDB > it would be awesome to see if we could have a changes feed per partition. > That would be a really nice feature. > > Cheers > Garren > > On Tue, Apr 21, 2020 at 5:51 PM Adam Kocoloski <kocol...@apache.org> wrote: > >> 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. >>>> >> >>
