couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glynn Bird <>
Subject Re: _all_docs collation
Date Thu, 26 Mar 2020 09:45:03 GMT
It's not something I was aware of, but it's certainly a known "feature",
documented here:

(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 <> 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]

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