couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Kocoloski <kocol...@apache.org>
Subject Re: Relaxo Ruby gem no longer targets CouchDB
Date Fri, 17 Feb 2017 01:17:07 GMT
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.traveller@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 <kocolosk@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.traveller@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.traveller@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
>> 


Mime
View raw message