couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hans J Schroeder>
Subject Re: CouchDB 2.0: breaking the backward compatibility
Date Sat, 19 Jul 2014 08:23:57 GMT
I am also -1. I would also be careful with API and JSON changes. At least there must be a compatibility
Maybe we can consolidate all meta data in a "_" sub object, but rewrite the JSON docs on the
fly in compatibility mode to the old structure.

When talking changes, I would recommend to make the "type" field a mandatory meta field and
allow the indexer
to use it. This can dramatically reduce on-demand indexing time especially on big databases
databases with many new document writes.



On 18 Jul 2014, at 22:15 , Jan Lehnardt <> wrote:

> I’m major -1 on substantial API changes *just* because we are having some
> by necessity of getting BigCouch in.
> The minor improvements mentioned previously in this thread sound reasonable,
> but changing the main JSON format seems like a rather bad idea as it will
> just break all clients. While the scenario is a little different, I’d like to
> avoid a Python 3 kind of situation (I think CouchDB 2.0 has more to offer over
> 1.0 than Python 3 had over 2, but still, there is no need to make this harder
> for our users, if we don’t have to).
> That said, we likely want to evolve the API at some point and I think we should
> nail down a strategy on *how* to do that, before getting into the details of
> what should change.
> One option, and I haven’t thought this through, would be to use separate ports
> for a new API endpoint that we can evolve while keeping the current one. And
> we can do the deprecation and switch dance some time in the future. We could
> even try multiple competing APIs, even non HTTP APIs (all things, I’d love to
> see, so we can learn from them). Of course there is a certain overhead in
> maintaining this all, and I don’t know if there are any roadblocks in the way
> BigCouch works today for implementing this.
> Best
> Jan
> --
> On 17 Jul 2014, at 21:03 , Russell Branca <> wrote:
>> I would also love to see _rev renamed, and I think it's a good
>> opportunity to flip around all the meta info as well. I'm still
>> partial to moving the relevant metadata into the headers, and no
>> longer including any _* fields in the doc, but I know there are
>> proponents on both sides of the coin there. The most recent proposal I
>> could find is to move all the metadata into a '_' field [1]. In 2.0 I
>> would like to see us move all metadata into headers or into the '_'
>> field, and rename 'rev'. There's a lot of code overlap for the two so
>> it seems like an opportune time to do it.
>> I wonder if it's reasonable to make the use of a '_' field or exposed
>> through headers configurable. I'm not sure it's a great idea to do so,
>> but it's at least worth thinking about.
>> Exposing conflicts by default is another thing I'm keen on. The
>> question is how to make it "fail" loudly so that client libraries
>> don't just think it's the document body. An aggressive approach send a
>> list of conflict revs rather than a doc object which will break all
>> existing parsers and require users to deal with. Then if you want a
>> particular rev, you'll need to specify it in the request.
>> We could also cleanup the API endpoints to make them more RESTful. IMO
>> things like _all_dbs and _all_docs should be the top level endpoints
>> and the current info endpoints moved to _info or some such.
>> Along the lines of API cleanup is the capabilities engine. I think
>> this would be a great thing to land, and if done properly could be a
>> self defining REST endpoint showing all the things the server is
>> capable of and how to reach them.
>> -Russell
>> [1]
>> On Thu, Jul 17, 2014 at 2:14 AM, Robert Samuel Newson
>> <> wrote:
>>> Great point, +1 to just making that change on master right now.
>>> B.
>>> On 16 Jul 2014, at 22:35, Robert Kowalski <> wrote:
>>>> I would like to see 'JSONP responses should be sent with a
>>>> "application/javascript"' (
>>>> beside the two merges in the 2.0 release - it is a small, but breaking
>>>> change and the original issue is flying around in Jira for years.
>>>> Best,
>>>> Robert
>>>> 2014-07-13 22:17 GMT+02:00 Robert Samuel Newson <>:
>>>>> Since we follow semantic versioning, the only meaning behind naming our
>>>>> next release 2.0 and not 1.7 is that it contains backwards incompatible
>>>>> changes.
>>>>> It’s for the CouchDB community as a whole to determine what is and
>>>>> in a release. Certainly merging in bigcouch and rcouch are a huge part
>>>>> the 2.0 release, but they aren’t necessarily the only things. If they
>>>>> hadn’t changed the API in incompatible ways, they wouldn’t cause
a major
>>>>> version bump.
>>>>> With that said then, I’m interested in hearing what else, besides the
>>>>> merges, we feel we want to take on in our first major revision bump in
>>>>> approximately forever? At minimum, I would like to see a change that
>>>>> us to use versions of spidermonkey released after 1.8.5, whatever that
>>>>> change might be.
>>>>> B.
>>>>> On 13 Jul 2014, at 20:31, Joan Touzet <> wrote:
>>>>>> Improving the view server protocol is a great idea, but it is appropriate
>>>>>> for a 2.0 timeframe? I would think it would make more sense in a
>>>>>> timeframe, given 2.0 is all about merging forks, not writing new
>>>>>> entirely from scratch.
>>>>>> -Joan
>>>>>> ----- Original Message -----
>>>>>> From: "Robert Samuel Newson" <>
>>>>>> To:
>>>>>> Sent: Sunday, July 13, 2014 8:52:40 AM
>>>>>> Subject: Re: CouchDB 2.0: breaking the backward compatibility
>>>>>> Adding mvcc for _security is a great idea (happily, Cloudant have
>>>>> so very recently, so I will be pulling that work over soon).
>>>>>> A better view server protocol is also a great idea.
>>>>>> On 13 Jul 2014, at 13:13, Samuel Williams <
>>>>>> wrote:
>>>>>>> On 13/07/14 23:47, Alexander Shorin wrote:
>>>>>>>> Our view server is compiles functions on each view index
>>>>>>>> instead of reusing inner cache. This is because of out-dated
>>>>>>>> others design function are works differently from views.
While it's
>>>>>>>> good to change and improve query server protocol completely,
this task
>>>>>>>> requires more time to be done. We should have a least plan
B to do
>>>>>>>> small steps in good direction.
>>>>>>> As already suggested, here is my proposal for 2.0 view/query
>>>>>>> I welcome people to suggest improvements/changes/ideas.
>>>>>>> Kind regards,
>>>>>>> Samuel

View raw message