couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Hall <>
Subject Re: _all_docs collation
Date Thu, 26 Mar 2020 12:42:58 GMT
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 


On 3/26/20 11:18 AM, Garren Smith wrote:
> Oh interesting, reading the documentation more carefully I see we have 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 <> wrote:
>> 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]

View raw message