couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Samuel Newson <rnew...@apache.org>
Subject Re: Partition query endpoints in CouchDB 4.0
Date Tue, 21 Apr 2020 20:35:48 GMT
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 <garren@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 <kocolosk@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 <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