couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <paul.joseph.da...@gmail.com>
Subject Re: CouchDB 2.0: breaking the backward compatibility
Date Tue, 15 Jul 2014 07:23:27 GMT
+1 to zlib/base64 strings as long as we make sure that the string
format is trivially and directly parseable (ie, no regex requirement
for parsing).

On Mon, Jul 14, 2014 at 4:30 PM, Robert Samuel Newson
<rnewson@apache.org> wrote:
> Hrm, no, I think those would remain as non_neg_integer(), but the fate of single-node
is not yet determined.
>
> B.
>
> On 14 Jul 2014, at 19:36, Joan Touzet <wohali@apache.org> wrote:
>
>> Yes to all 3 of your questions.
>>
>> Would we mandate this format even for single-node? We could "fake it" as if it was
a q=1 db, i.e.
>>
>> "seq":"couchdb@foo,000-fff,12"
>>
>> If you want to allow replication from 1.x hosts you'd have to be more lenient ("should"
not "must").
>>
>> ----- Original Message -----
>> From: "Robert Samuel Newson" <rnewson@apache.org>
>> To: dev@couchdb.apache.org
>> Sent: Monday, July 14, 2014 10:34:21 AM
>> Subject: Re: CouchDB 2.0: breaking the backward compatibility
>>
>>
>> Another thought occurs; BigCouch has a different format for update_seq that is notoriously
ugly.
>>
>> We obviously need to encode more information for a sharded cluster (the update_seq
of each shard, the range that it’s for and the node it resides on) but BigCouch also had
to be compatible with CouchDB 1.x installations, so we add the sum of update sequences on
the front, to trick the old replicator into working.
>>
>> While it is not necessary for a human to be able to read an update_seq value (aka:
you should treat it as opaque JSON), it’s often useful to unpack these for diagnostic purposes.
Our use of term_to_binary confounds non-erlang libraries from doing so.
>>
>> I propose we fix that in 2.0 which would require that the replicator checkpoints
every N updates, and not when it sees the current update_seq exceed some delta from the update_seq
of the last checkpoint.
>>
>> An example readable format would be;
>>
>> "seq":"couchdb@foo,000-ccc,12:couchdb@bar,d00-fff,10"
>>
>> that is, a formatted string.
>>
>> A few questions;
>>
>> 1) Should we obscure hostnames? (we could run then forward through sha1 or even pbkdf2,
akin to how .known_hosts is protected by ssh)
>> 2) should we gzip encode the result?
>> 3) should we base64 the result?
>>
>> I think "yes" to all questions (and we would obviously have to base64 if we gzipped).
>>
>> Thoughts?
>>
>> B.
>>
>>
>> On 13 Jul 2014, at 21:23, Paul Davis <paul.joseph.davis@gmail.com> wrote:
>>
>>> Changing the default respones for conflicts to include all versions
>>> (or no version).
>>>
>>> Fix the list API (inside couchjs) so that its a pure callback like
>>> everything else. Not sure if we should necessarily completely revamp
>>> the whole query server protocol for 2.0. Given that its not user
>>> facing I'm less inclined to think it needs to be in a major release,
>>> ie we could add a new protocol in a minor release after 2.0.
>>>
>>> We should rename _rev to _mvcc (or _token or _lock or anything not
>>> _rev) finally.
>>>
>>> Removing all metadata from document bodies has been an oft requested change.
>>>
>>> Seems like there was a list of these things floating around a long time ago.
>>>
>>> On Sun, Jul 13, 2014 at 3:17 PM, Robert Samuel Newson
>>> <rnewson@apache.org> wrote:
>>>>
>>>> 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