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.b...@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 <gar...@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 > > >
