Hi everyone, Recently, Garren and Robert started making progress on this proposal via a PR:
https://github.com/apache/couchdb/pull/1480 and specifically: https://github.com/apache/couchdb/pull/1480#issuecomment-409565736 which has lead to me with a strong -0.75 on the proposed endpoint of: /db/_partition/:partitionkey/_designdoc/name/_view/viewname Here's why. We absolutely must get rid of port 5986, which is currently the only way to get to actual disk-level shards in CouchDB today. The route for that will probably look something like: /db/_shard/00000000-1fffffff/... This is critical for cluster-level administration, health checks, etc. and to fully remove the old couch_httpd code from the codebase (which is desperately overdue for happening, and must happen prior to a 3.0 release). I'm sad we don't have this code yet, especially since like children in a well-stocked larder we're rushing to the jams and pies before having our main courses, but such is the nature of shiny things. Now I see we are introducing view partitions, which to me really should be below the view portion here: /db/_designdoc/name/_view/viewname/_partition/:partitionkey/ End users who are new to CouchDB 2.x are still just learning about shards. Partitions are only going to further muddy the waters. As I said on IRC, "i 100% guarantee you that people will not understand the difference between a db shard and a db partition if we introduce both concepts without careful thought :)" To me, this is not carefully thought out. Garren mentions this will also surface for find/index, and thus makes a case for it being farther up. But I argue that with /db/_shard and /db/_partition people will have no idea what they are doing. Please help me disentangle this ball of yarn. And don't make the new feature "more important" than shard-level access, it's not. -Joan
