couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Kocoloski <kocol...@apache.org>
Subject Re: Partition query endpoints in CouchDB 4.0
Date Tue, 21 Apr 2020 15:51:33 GMT
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 <kjsnavely@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 <iilyak@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 <rnewson@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.
>> 


Mime
View raw message