Joan, I'd like to reassure that the question has been considered in reasonable depth. My wording was looser than it should have been.
However, the solution is non-obvious enough that a single "correct" way forward probably doesn't exist and reasonable people can argue in many directions. A perfect solution isn't possible within the constraints of the CouchDB API IMO, which leaves us with finding the least-bad solution in many ways, and trying to choose one where a path is open for improving longer term and reducing the necessary level of compromise. For example, the move from calling it "shard local querying" (in the original proposal to the list) to "partitioned databases" was in large part driven directly from usability concerns and user mental model confusion -- and a desire to separate out via terminology what is more a developer level concern (logical data partitions) from admin level concerns (physical shard layout) such that the developer's abstraction has a clean and non-leaky mapping to what an admin is managing. As to the exact API, my view is that making the feature very front-and-centre is less likely to be confusing than it being "hidden" lower down in the API structure, as it's an important concept to get straight early on if your use-case requires it. This also necessarily brings documentation further to the fore as we can't relegate discussion to the API reference as easily, which I also view as a positive. -- Mike. On Thu, 2 Aug 2018, at 12:17, Joan Touzet 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
