couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Garren Smith <gar...@apache.org>
Subject Re: _all_docs collation
Date Thu, 26 Mar 2020 12:53:00 GMT
Honestly, I'm not sure. I'm fine with keeping raw collation. But it was
definitely confusing when thinking about _all_docs.


On Thu, Mar 26, 2020 at 2:43 PM Jonathan Hall <flimzy@flimzy.com> wrote:

> Would changing _all_docs, but keeping raw collation as an option, really
> simplify anything anyway?
>
> Or are you proposing removing the raw collation option entirely?
>
> Or maybe you're proposing this more as a UX change, than a technical
> simplification?



>
> Jonathan
>
>
> On 3/26/20 11:18 AM, Garren Smith wrote:
> > Oh interesting, reading the documentation more carefully I see we have
> raw
> > collation
> >
> https://docs.couchdb.org/en/stable/ddocs/views/collation.html#raw-collation
> > So _all_docs is using that and that explains why an object comes before a
> > string.
> > So do we want to keep raw collation for _all_docs?
> >
> > On Thu, Mar 26, 2020 at 11:45 AM Glynn Bird <glynn.bird@gmail.com>
> wrote:
> >
> >> It's not something I was aware of, but it's certainly a known "feature",
> >> documented here:
> >> https://docs.couchdb.org/en/stable/ddocs/views/collation.html#all-docs
> >>
> >> (probably because all keys are strings in all_docs, whereas they can be
> all
> >> sorts of mixed types with a view, and ascii collation would be faster
> with
> >> that assumption)
> >>
> >> On Thu, 26 Mar 2020 at 07:12, Garren Smith <garren@apache.org> wrote:
> >>
> >>> Hi Everyone,
> >>>
> >>> While working on the Mango implementation for FDB, I've noticed that
> >>> _all_docs has some weird
> >>> ordering collation. If you do something like GET
> >> /db/_all_docs?startkey={}
> >>> it will return all the documents even though in view collation an
> object
> >> is
> >>> ordered after strings. The reason I've noticed this is that in the
> >>> pouchdb-find tests we have a few tests that check that {selector: {_id:
> >>> {$gt: {}}} return all the docs in the database [0].
> >>>
> >>> This ordering feels wrong to me, but I'm guessing its been around for a
> >>> while. Currently for _all_docs on FDB, we have it that if you did the
> >> above
> >>> startkey query, it would not return any documents as we are following
> the
> >>> view collation ordering.
> >>>
> >>> I want to know whether we should keep the old _all_docs ordering or
> >> rather
> >>> standardize on view collation ordering everywhere?
> >>>
> >>> I would prefer we change it, but I'm not sure the implications of that
> >> for
> >>> client libraries and users.
> >>> Changing it would be a breaking change, but since 4.0 is going to be a
> >> lot
> >>> of breaking change I think this would be our best chance to do this.
> >>>
> >>> Cheers
> >>> Garren
> >>>
> >>>
> >>>
> >>> [0]
> >>>
> >>>
> >>
> https://github.com/nolanlawson/pouchdb-find/commit/e1ca2e2d18041f05a3d19bce4254f4d7b349ad20
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message