Ah OK, this helps. I read “query server” as “the system that processes queries submitted to the database” (where we added Mango) rather than the one that indexes documents based on user-defined javascript functions. You’re right that the protocol there could use some love, and that is hasn’t been a priority for the committers.
Apache Cassandra has matured nicely over the years and has certainly proven itself in a number of significant deployments. The CouchDB 2.0 clustering features do have a lot in common with Cassandra’s approach; both can broadly be described as “Dynamo-inspired". CouchDB’s replication capability is a real differentiator, and I also think the HTTP+JSON interface is a cleaner match for web and mobile application development. The ASF is a big tent :) I honestly do appreciate you taking the time to share this feedback. Cheers, Adam > On Feb 13, 2017, at 12:38 AM, Samuel Williams > <space.ship.travel...@gmail.com> wrote: > > Hi Adam, feel free to let me know what parts of the feedback were > confusion and I'll attempt to clarify. > > Regarding the query server, I assume you mean that the query server > was refactored on the Erlang side, but I was under the impression that > the externally visible API is largely the same. I made some proposals > here ages ago > https://docs.google.com/document/d/1JtfvCpNB9pRQyLhS5KkkEdJ-ghSCv89xnw5HDMTCsp8/edit?usp=sharing > and of course I was hoping for discussion but essentially nothing > happened to improve the situation since I wrote that document 4 years > ago. > > Some of the key points: > - Still does map well to the global scope imposed by languages like > Ruby, C++, etc. > - `rereduce` provides function directly while map use ddoc. > inconsistent and hard to compile AOT. > - No support for parallel computation or compression. > - Restricted to JSON which is a pretty major overhead for the query > server from my profiles several years ago. > > Another big issue is the loss of the _bulk_save all or nothing API, > which I used for transnational updates. Without that API, existing > code that worked with 1.0 was broken. > > The sharding made it a pain to set up and migrate existing 1.0 data > stores, yes probably my fault but it broke at least one production > site while I figured it out. > > Web interface is still pretty limited, some regressions in > functionality in Fauxton, general lack of direction to improve things. > > The idea of CouchDB being an application server largely ignored, left > to stagnate (e.g. lists). > > It's my humble opinion that for CouchDB 2.0, for the common use case > that it appears to be addressing, Cassandra would be a better option. > > But, look, what do I know. This is my opinion and take it with two > cents of salt :) I'm not trying to provoke an argument. I may be > misinformed, wrong, etc, it wouldn't be the first time. > > Kind regards, > Samuel > > > > > On 13 February 2017 at 17:28, Adam Kocoloski <kocol...@apache.org> wrote: >> Hi Samuel, thanks for sending this note. I have to admit that I find some of >> the feedback confusing — a new query server was one of the headline features >> of 2.0 — but that’s neither here nor there. It’s good of you to provide a >> clear statement about the future of the Relaxo projects. Cheers, >> >> Adam >> >>> On Feb 11, 2017, at 5:48 PM, Samuel Williams >>> <space.ship.travel...@gmail.com> wrote: >>> >>> My bad, the gem actually "Relaxo::QueryServer" :) But I'm sure no one cares. >>> >>> On 12 February 2017 at 11:46, Samuel Williams >>> <space.ship.travel...@gmail.com> wrote: >>>> Hi Guys, >>>> >>>> It's with a heavy (and slightly frustrated) heart that I've decided to >>>> stop investing time and effort into CouchDB. The 2.0 release moves >>>> further away from the core principals of CouchDB that made it >>>> attractive to me. In addition, a lot of issues in the core design of >>>> CouchDB (e.g. better query server & schema) seem to be ignored for >>>> years and so I've given up hope that there would be improvements. >>>> >>>> I'm not trying to be negative too much, the 2.0 release looks really >>>> great in a lot of ways - it's simply not what I'm after for my >>>> personal projects. >>>> >>>> The main point of this email is regarding the gems I maintained and >>>> published. >>>> >>>> For several years, I maintained an unpopular set of Ruby gems: >>>> "Relaxo", "Relaxo::Model" and "Relaxo::Query::Server". They are not >>>> used much but they were pretty decent client libraries. I'm >>>> refactoring the first two gems (never had a 1.0 release) as a Git >>>> based transactional database. So, from the next release (probably >>>> 0.6.0), they will have breaking API changes and no longer work with >>>> CouchDB. The third one - Relaxo::Query::Server, may be modified to be >>>> a git-based map-reduce server, so eventually that will be unavailable >>>> too. >>>> >>>> I'm just wanted to let anyone know, officially, what's happening with >>>> these gems as I feel it would be unfortunate for someone to be >>>> depending on them and not know what's happening or why. If you are >>>> stuck using these gems, know that they are now unmaintained in their >>>> current form, but you can pin to version "~> 0.4.0" and things would >>>> keep working. In addition, I've updated the confluence wiki to point >>>> to the best other option I know of (Couchrest) and removed links to >>>> these gems. When I update these gems, later today, they should not be >>>> published on the CouchDB news feed as they are no longer relevant. >>>> >>>> Thanks so much everyone. >>>> >>>> Kind regards, >>>> Samuel >>
