couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Garren Smith <gar...@apache.org>
Subject Re: Partition query endpoints in CouchDB 4.0
Date Tue, 21 Apr 2020 17:51:34 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message