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 <[email protected]> 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 <[email protected]> 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/%[email protected]%3E >> >> On Thu, Jul 17, 2014 at 2:14 AM, Robert Samuel Newson >> <[email protected]> wrote: >>> Great point, +1 to just making that change on master right now. >>> >>> B. >>> >>> On 16 Jul 2014, at 22:35, Robert Kowalski <[email protected]> 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 <[email protected]>: >>>> >>>>> >>>>> 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 <[email protected]> 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" <[email protected]> >>>>>> To: [email protected] >>>>>> 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 < >>>>> [email protected]> 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 >>>>>> >>>>> >>>>> >>> >
