There was a discussion on #couchdb-dev and the proposal is that instead of using _shards we would rather have _nodes so we could requests like /_node/ couchdb@192.168.0.3/shards%2f0000-1ffff%2ffoo/docid
That then allows us to use _partition as an endpoint for the partition work without us confusing end users with _shard and _partition. Full IRC conversation below: 14:25 W<+Wohali> i'd say /_node/$name/$db/_shards instead though 14:25 W<+Wohali> from the general to the specific? 14:45 R<@rnewson> I don't mind /_node too much 14:49 J<+jan____> Wohali: I’m thinking more /_node/$x/ somewhat analogous to 5986 conceptually, so everything on there is per-node-only, so no notion of a $db, and only shards 14:49 J<+jan____> very nitpick of course 14:49 R<@rnewson> ah sorry, I am not even thinking 14:50 R<@rnewson> /_node/ couchdb@192.168.0.3/shards%2f0000-1ffff%2ffoo/docid/attname (etc) 14:50 R<@rnewson> no need for _shards magic 14:50 R<@rnewson> the shards have proper database names 14:50 W<+Wohali> that's in line with our original thinking that under /_node/<nodename> was, effectively, couch_httpd 14:51 R<@rnewson> that is /_node/$nodename/$dbname where $dbname is what you'd use on port 5986 (the %2f encoding et al) 14:51 W<+Wohali> which would be the easiest way to get rid of 5986 14:51 R<@rnewson> right 14:51 R<@rnewson> yes 14:51 R<@rnewson> it would allow us to close the port but not (yet) delete couch_httpd_* modules 14:51 W<+Wohali> and makes a doc rewrite easy. so yeah, i like that 14:52 R<@rnewson> the things already exposed under /_node/$node don't mess us up? I think we were careful but it's been a while 14:52 R<@rnewson> in that I think it was just two global handlers 14:52 W<+Wohali> _stats and _system for sure are there 14:53 R<@rnewson> ok, those fit perfectly 14:53 W<+Wohali> _config too 14:53 R<@rnewson> ditto 14:53 W<+Wohali> we'll want _dbs and _nodes there 14:53 R<@rnewson> ok, so it really could just be everything On Thu, Aug 2, 2018 at 1:17 PM, Joan Touzet <woh...@apache.org> wrote: > > I do agree with the confusion aspect of shards and partitions, and > > I'm unsure exactly the way forward here yet :( > > This is all I care about, and I'm cross that this hasn't been given > more serious consideration, given CouchDB is already confusing for people > coming from other databases. Make all the new features you want, but not > at the expense of usability. > > I've raised the issue but I don't have any great idea, other than to say > I think /db/_shard/<range> is a suitable place for shard-specific > operations > to happen. > > Help from this list is important before the new endpoint lands. > > -Joan >
