couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hans J Schroeder ...@cloudno.de>
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
switch.
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
and 
databases with many new document writes.

Cheers

--
Hans    

On 18 Jul 2014, at 22:15 , Jan Lehnardt <jan@apache.org> 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 <chewbranca@apache.org> 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] http://mail-archives.apache.org/mod_mbox/couchdb-dev/201312.mbox/%3C529DE44C.4090400@bigbluehat.com%3E
>> 
>> On Thu, Jul 17, 2014 at 2:14 AM, Robert Samuel Newson
>> <rnewson@apache.org> wrote:
>>> Great point, +1 to just making that change on master right now.
>>> 
>>> B.
>>> 
>>> On 16 Jul 2014, at 22:35, Robert Kowalski <rok@kowalski.gd> wrote:
>>> 
>>>> I would like to see 'JSONP responses should be sent with a
>>>> "application/javascript"' (https://github.com/apache/couchdb/pull/236)
>>>> 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 <rnewson@apache.org>:
>>>> 
>>>>> 
>>>>> 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
isn’t
>>>>> in a release. Certainly merging in bigcouch and rcouch are a huge part
of
>>>>> 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
two
>>>>> 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
allows
>>>>> 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 <wohali@apache.org> 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
3.0
>>>>>> timeframe, given 2.0 is all about merging forks, not writing new
features
>>>>>> entirely from scratch.
>>>>>> 
>>>>>> -Joan
>>>>>> 
>>>>>> ----- Original Message -----
>>>>>> From: "Robert Samuel Newson" <rnewson@apache.org>
>>>>>> To: dev@couchdb.apache.org
>>>>>> 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
done
>>>>> 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 <
>>>>> space.ship.traveller@gmail.com> wrote:
>>>>>> 
>>>>>>> 
>>>>>>> On 13/07/14 23:47, Alexander Shorin wrote:
>>>>>>>> Our view server is compiles functions on each view index
update
>>>>>>>> instead of reusing inner cache. This is because of out-dated
protocol:
>>>>>>>> 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
server:
>>>>>>> 
>>>>>>> 
>>>>> https://docs.google.com/document/d/1JtfvCpNB9pRQyLhS5KkkEdJ-ghSCv89xnw5HDMTCsp8/edit
>>>>>>> 
>>>>>>> I welcome people to suggest improvements/changes/ideas.
>>>>>>> 
>>>>>>> Kind regards,
>>>>>>> Samuel
>>>>>> 
>>>>> 
>>>>> 
>>> 
> 


Mime
View raw message