Re: [DISCUSS] Deprecate custom reduce functions

;> I think I agree that we should keep the custom reduce feature, but I’m in >> favour of disabling it by default for the reasons stated in this thread. >> >> Or in voting terms: >> >>> On 13. Oct 2020, at 22:21, Robert Samuel Newson wrote: >>> >

Re: [DISCUSS] Deprecate custom reduce functions

duce function would mean building one unique index >> for each value that needs to be summed, which I expect would be a lot >> less efficient. >> >> But maybe I'm overlooking a more clever and efficient alternative. >> >> Jonathan >> >> >&

Re: [DISCUSS] Deprecate custom reduce functions

duce function would mean building one unique index for each value > that needs to be summed, which I expect would be a lot less efficient. > > But maybe I'm overlooking a more clever and efficient alternative. > > Jonathan > > > On 10/13/20 6:31 PM, Robert Samuel

Re: [DISCUSS] Deprecate custom reduce functions

; reason to deprecate it, but rather a user-experience reason. Is this correct? > > If my understanding is correct, I'm not excited about the proposal, but > before I dive further into my thoughts, I'd like confirmation that I actually > understand the proposal, and am not worried about s

[DISCUSS] Deprecate custom reduce functions

Hi All, As part of CouchDB 4.0, which moves the storage tier of CouchDB into FoundationDB, we have struggled to reproduce the full map/reduce functionality. Happily this has now happened, and that work is now merged to the couchdb main branch. This functionality includes the use of custom

Re: [DISCUSS] Prometheus endpoint in CouchDB 4.x

Hi, I don't see why this can't be a new endpoint (emitting the normal Prometheus format) that couchdb administrators can choose to enable (and leave it disabled by default, returning a 404). I agree with the general view that content type negotiation doesn't really work well in practice, and

Re: [ANNOUNCE] Glynn Bird joins the PMC

Congrats to you Glynn, very glad to have you onboard! B. > On 14 Sep 2020, at 17:44, Will Holley wrote: > > Congrats Glynn! > > On Mon, 14 Sep 2020 at 17:29, Joshua Mintz wrote: > >> Congrats, Glynn! >> >> On Mon, Sep 14, 2020 at 12:23 PM Jan Lehnardt wrote: >> >>> Congratulations Glynn!

Re: [VOTE] Release Apache CouchDB 3.1.1 (RC2)

Hi, There is no existing HTTP request header that I'm aware of that could cover this and inventing custom HTTP headers is not recommended (CouchDB has a fair few but I don't want to add to that pile). My preference is to remove the query parameter without replacement for this release, leaving

Re: Is it time to merge prototype/fdb-layer to master?

Agree that its time to get the fdb-layer work into master, that's where couchdb 4.0 should be being created. thanks for preserving the imported ebtree history. > On 9 Sep 2020, at 17:28, Paul Davis wrote: > > The merge on this turned out to be a lot more straightforward so I > think its

Re: [DISCUSS] Rename default branch to `main`

I'm +1 in favour of renaming to 'main'. > On 9 Sep 2020, at 18:26, Alessio 'Blaster' Biancalana > wrote: > > I'm not against nor in favor :-D > Words matter but in my opinion git's master was never _that_ master. > Anyway, if it bothers someone... let's do this! > > Concerning open PRs, I

Re: Is it time to merge prototype/fdb-layer to master?

Agree that its time to get the fdb-layer work into master, that's where couchdb 4.0 should be being created. thanks for preserving the imported ebtree history. > On 9 Sep 2020, at 17:28, Paul Davis wrote: > > The merge on this turned out to be a lot more straightforward so I > think its

Re: Announcing Opservatory: 24/7 CouchDB Observation and Analysis

Nice :) > On 9 Sep 2020, at 18:32, Nick Vatamaniuc wrote: > > That looks really nice, Jan. Thanks for sharing! > > On Wed, Sep 9, 2020 at 1:29 PM Alessio 'Blaster' Biancalana > wrote: >> >> Wow, that's _amazing_. I'm glad seeing this kind of effort in an ecosystem >> like the one of CouchDB,

Re: [DISCUSS] Reduce on FDB take 3

yes. So I’m not +1 >> yet. >> >> I fixed the spurious conflicts at >> https://github.com/apache/couchdb/pull/3033. >> >> -- >> Robert Samuel Newson >> rnew...@apache.org >> >> On Fri, 24 Jul 2020, at 14:59, Garren Smith wrote: >

Re: [DISCUSS] Reduce on FDB take 3

V map queries. >> >> Kyle >> >> On Thu, Jul 23, 2020, 2:17 PM Robert Samuel Newson >> wrote: >> >>> I (perhaps obviously) don't agree that I'm tying myself to old CouchDB or >>> failing to embrace FDB. FDB is a toolkit and does not, to my min

Re: [DISCUSS] Reduce on FDB take 3

I (perhaps obviously) don't agree that I'm tying myself to old CouchDB or failing to embrace FDB. FDB is a toolkit and does not, to my mind, force us down any particular path. I haven't sat down to modify couch_views in the manner I've suggested (where ebtree is used as designed; being fed the

Re: [DISCUSS] Reduce on FDB take 3

’m very glad to see a departure from couch_btree’s approach of > dynamically modifying the “order” of the “b+tree” based on the size of the > reduction. Such an ugly edge case there ... > > Cheers, Adam > >> On Jul 21, 2020, at 8:48 AM, Robert Newson wrote: >> >> Than

Re: [DISCUSS] couchdb 4.0 transactional semantics

No, I would not. I was thinking only of the previous major release. so a 3.x.y that adds bidirection replication compatibility with 4.0.0. B. > On 16 Jul 2020, at 21:50, Joan Touzet wrote: > > > > On 2020-07-16 2:24 p.m., Robert Samuel Newson wrote: >> Agreed on all 4

Re: [DISCUSS] couchdb 4.0 transactional semantics

Agreed on all 4 points. On the final point, it's worth noting that a continuous changes feed was two-phase, the first is indeed over a snapshot of the db as of the start of the _changes request, the second phase is an endless series of subsequent snapshots. the 4.0 behaviour won't exactly

Re: [DISCUSS] couchdb 4.0 transactional semantics

ransaction return a 400 error. We won't emit > anything out while rows are accumulated, so users don't get partial > data, it will be every row requested or a 400 error (so no chance of > perceived data loss). Users may retry if they think it was a temporary > hiccup or may use a small limi

[DISCUSS] couchdb 4.0 transactional semantics

Hi All, I'm concerned to see the restart_fold function in fabric2_fdb (https://github.com/apache/couchdb/blob/prototype/fdb-layer/src/fabric/src/fabric2_fdb.erl#L1828) in the 4.0 development branch. The upshot of doing this is that a CouchDB response could be taken across multiple snapshots

Re: Newsfeed IFRAME in Fauxton and IP collection

Hi, I share the discomfort in fauxton making a remote connection without warning and agree with Jan that some confirmation screen should be added. It's also fine for this to be on master while it develops, master is not a release and is not guaranteed to be releasable either. Anyone deploying

Re: [PROPOSAL] Future security announcement policy

ncements and their categorisation. They allow me to >> decide, whether I have to pencil in an upgrade for the date of the release >> or not. So *if* we decide to do this, I’d advocate to include severity and >> mitigation information in broad strokes at least. >> I’m +0 on making

[PROPOSAL] Future security announcement policy

Hi All, We've just published a CVE and it made me think about our current announcement policy. Currently, when we receive notice of a security issue, the PMC investigate it, fix it if it's genuine, then we prepare and publish a release without mentioning the security issue. A week after

Re: [DISCUSS] _changes feed on database partitions

Per-shard will not mean anything from 4.0 onward so at least I was not thinking of that. per-partition has meaning from 3.0 onward as partitions are user defined. B. > On 14 May 2020, at 22:11, Joan Touzet wrote: > > > > On 2020-05-13 10:07 a.m., Robert Samuel Newson wrote

Re: [DISCUSS] _changes feed on database partitions

Hi, Yes, I think this would be a good addition for 3.0. I think we didn't add it before because of concerns of accidental misuse (attempting to replicate with it but forgetting a range, etc)? Whatever the reasons, I think exposing the per-partition _changes feed exactly as you've described

Re: [DISCUSS] length restrictions in 4.0

h that. > > https://en.wikipedia.org/wiki/Comparison_of_file_systems > > On Tue, May 12, 2020 at 5:29 PM Robert Samuel Newson > wrote: >> >> You'd have to replicate "back" and adjust the target db name to fit. It >> doesn't feel like a terrible hardship. >> &

Re: [DISCUSS] length restrictions in 4.0

You'd have to replicate "back" and adjust the target db name to fit. It doesn't feel like a terrible hardship. > On 12 May 2020, at 21:54, Joan Touzet wrote: > > I presume the workaround would be "Replicate back to CouchDB 3.x, but > truncate to 236 characters in the process?" You'd lose

Re: [DISCUSS] length restrictions in 4.0

ce, present or future. > > -- > Robert Samuel Newson > rnew...@apache.org > > On Tue, 12 May 2020, at 19:52, Nick Vatamaniuc wrote: >> I still like it. It's only 18 bytes difference but it introduces one >> more compatibility issue. At least for 4.x, it would be nice to have &

Re: [DISCUSS] length restrictions in 4.0

Sorry to let this thread drop. Nick, are you still preferring 238? B. > On 4 May 2020, at 21:06, Robert Samuel Newson wrote: > > Ah, ok, understood. I don't think that's a compelling reason to fix our > maximum database name length at 238. > > CouchDB 4.0 will be

Re: [VOTE]: Deprecate _update Endpoint

+1. > On 6 May 2020, at 12:57, Jan Lehnardt wrote: > > Hey all, > > it appears we missed an item in our 3.0 deprecations list and we should > clear this up. > > We have as of yet failed to capture consensus here about the > deprecation of the _update endpoint. I think we *have* consensus

Re: [DISCUSS] length restrictions in 4.0

p > the same database name on both systems, that's what I meant. > > On Mon, May 4, 2020 at 3:15 PM Robert Samuel Newson > wrote: >> >> The 'timestamp in filename' is only on the internal shards, which would not >> be part of a replication between 2.x/3.x and 4

Re: [DISCUSS] length restrictions in 4.0

. > On 4 May 2020, at 20:04, Joan Touzet wrote: > > I suspect he means when replicating back to a 3.x or 2.x cluster. > > On 2020-05-04 3:03 p.m., Robert Samuel Newson wrote: >> But we don't need to add a file extension or a timestamp to database names. >> B. >&g

Re: [DISCUSS] length restrictions in 4.0

name on whatever file system > the server was running on. In practice that was 255, then there is an > extension and a timestamp in the filename which made the db name limit > be 238 so I suggest to use that instead. > > -Nick > > On Mon, May 4, 2020 at 11:51 AM Robert Samuel New

Re: [DISCUSS] length restrictions in 4.0

r in this case users can easily replace signatures with hashes of > signatures. So I wouldn't worry about it to much. 512 sounds plenty to me. > > +1 to set hard limits on db name size and doc id size with proposed values. > > Best regards, > iilyak > > On 2020/05/01 18:36:45,

Re: [VOTE] Release Apache CouchDB 3.0.1

+1 RC2 macOS 10.15.4, erlang 22.3.2 sigs: ok make check: ok except reduce_builtin.js > On 3 May 2020, at 06:12, Nick Vatamaniuc wrote: > > +1 > > RC2 > > Ubuntu 18.04, Erlang 22.2.3 > > Sigs: ok > make check: ok > make release: ok > Fauxton (verify install, doc links, basic replication):

Re: [VOTE] Release Apache CouchDB 3.1.0

+1 RC2 macOS 10.15.4, erlang 22.3.2 sigs: ok make check: ok except reduce_builtin.js > On 3 May 2020, at 06:12, Nick Vatamaniuc wrote: > > +1 > > RC2 > > Ubuntu 18.04, Erlang 22.2.3 > > Sigs: ok > make check: ok > make release: ok > Fauxton (verify install, doc links, basic replication):

[DISCUSS] length restrictions in 4.0

Hello, There are other threads related to doc size (etc) limits for CouchDB 4.0, motivated by restrictions in FoundationDB, but we haven't discussed database name length and doc id length limits. These are encoded into FoundationDB keys and so we would be wise to forcibly limit their length

Re: API versioning

As a general direction, I like it, but the specific example of accept/content doesn't sit right with me. application/couchdb needs registering, which is a faff, and isn't appropriate imo as we have many different formats of request and response, which a content-type ought to capture. From the

Re: [DISCUSS] Streaming API in CouchDB 4.0

ll agree is a Good Thing) but it > also feels a bit wrong to ignore it as part of this work if we're > going to be modernizing our APIs. Though if we do pick up a good > versioning scheme then we could theoretically make those changes > easily enough. Plus, who doesn't want to rewrite chttpd

Re: [DISCUSS] Streaming API in CouchDB 4.0

all_docs >>>> All the fields in the bookmark make sense except timestamp. Why would it >>>> matter if the timestamp is old? What happens if a node's time is an hour >>>> behind another node? >>>> >>>> >>>>> On Thu, Apr 23

Re: [DISCUSS] Streaming API in CouchDB 4.0

"page" and "page number" are odd to me as these don't exist as concepts, I'd rather not invent them. I note there's no mention of page size, which makes "page number" very vague. What is "timestamp" in the bookmark and what effect does it have when the bookmark is passed back in? I guess, why

Re: Partition query endpoints in CouchDB 4.0

all views work either "global" or "partitioned" depending on the endpoint used. for 5.0 I'm +0 on removing the _partition endpoints, but we can take that vote at the time based on contemporary feedback. B. > On 21 Apr 2020, at 21:35, Robert Samuel Newson wrote: > &g

Re: Partition query endpoints in CouchDB 4.0

gt; >>>> Given that it unlikely that there are too many people using it and it is >>>> being noop in FDB world. I think we should deprecate and remove >> _partition >>>> endpoint. >>>> >>>> On 2020/04/20 21:04:58, R

Partition query endpoints in CouchDB 4.0

Hi All, I'd like to get views on whether we should preserve the _partition endpoints in CouchDB 4.0 or remove them. In CouchDB 4.0 all _view and _find queries will automatically benefit from the same performance boost that the "partitioned database" feature brings, by virtue of FoundationDB.

Re: Getting FDB work onto master

noting that https://ci-couchdb.apache.org/blue/organizations/jenkins/jenkins-cm1%2FPullRequests/detail/PR-2732/7/pipeline/ now fails because kerl isn't there. related? B. > On 30 Mar 2020, at 22:11, Robert Samuel Newson wrote: > > Nice, make check-fdb passes for me on that branch

Re: Getting FDB work onto master

Nice, make check-fdb passes for me on that branch (the 2nd time, the 1st time was a spurious failure, timing related). B. > On 30 Mar 2020, at 22:04, Robert Samuel Newson wrote: > > Hi, > > Great timing, I merged something to prototype/fdb-layer without the check > p

Re: Getting FDB work onto master

Hi, Great timing, I merged something to prototype/fdb-layer without the check passing, I'm trying this now. First note, the kerl line doesn't work but it seems there's a system wide erlang 20 install instead. B. > On 30 Mar 2020, at 19:50, Joan Touzet wrote: > > Hi everyone, hope you're

Re: [DISCUSS] Mango indexes on FDB

Hi, We had a long discussion on the CouchDB Slack on this topic, which I will brutally summarise; While we intend to update json indexes in the same transaction as the associated document update, there is a concern that this won't always be possible (large document and large number of indexes

Re: native encryption for couchdb 4.0?

Hi, Good feedback, thanks all. B. > On 15 Mar 2020, at 13:25, Dave Cottlehuber wrote: > > On Thu, 12 Mar 2020, at 17:35, Robert Samuel Newson wrote: >> Hi, >> >> Yes, platform independent, it's not custom C work, just calls into the >> existing crypto mo

Re: native encryption for couchdb 4.0?

documents were "exploded" or "flattened" into the individual data items within a document would not work nearly as well. B. > On 12 Mar 2020, at 17:35, Robert Samuel Newson wrote: > > Hi, > > Yes, platform independent, it's not custom C work, just calls

Re: native encryption for couchdb 4.0?

to access any part of it and this doesn't involve the user. B. > On 12 Mar 2020, at 17:17, Joan Touzet wrote: > > > > On 2020-03-12 12:29, Robert Samuel Newson wrote: >> Hi All, >> Our team at IBM are working on native encryption of document content f

native encryption for couchdb 4.0?

Hi All, Our team at IBM are working on native encryption of document content for the Cloudant service and are wondering if there'd be interest (or objection!) to this landing as a CouchDB feature? This is only targeted at the (future) CouchDB 4.0 release which introduces FoundationDB as the

Re: [VOTE] Release Apache CouchDB 3.0.0 (-rc3)

+1 MacOS 10.15.3 sigs: ok checksums: ok make check: pass make release: works B. > On 20 Feb 2020, at 00:16, Joan Touzet wrote: > > Dear community, > > I would like to propose that we release Apache CouchDB 3.0.0. > > Changes since last time: > >

Re: [Lazy Consensus] Raise minimum Erlang version for 3.0.0 to 20.3.8.11, Node version to 10

+1 > On 8 Oct 2019, at 18:13, Nick Vatamaniuc wrote: > > +1 > > Good call, Joan. > > On Tue, Oct 8, 2019 at 12:52 PM Joan Touzet wrote: >> >> I'm updating our build dependencies for CI in advance of the Jenkins >> move and 3.0.0. In the process I've got a number of platforms now on >> which

Re: CouchDB and future

couldn't find the reference from earlier, but I believe the > rules should be: > > If you have 1 node, set n=1. > If you have 2 nodes, set n=2. > If you have 3 or more nodes, set n=3. > > Anything else is a special case and isn't recommended. > > -Joan > > On 20

Re: CouchDB and future

Pulling this sentence out from much earlier in the thread; "N should be set to the number of nodes." That's not true and our docs should not say it today or be changed to say it in the future. N is how many copies of a document we'll maintain. If you had a 20 node cluster, you would not want

Re: CouchDB data processing endpoints

Hi, My rule of thumb here is whether any particular 'data processing endpoint' can be done better (or at all) within the database server than otherwise, as opposed to the original CouchDB position of adding such things to the database to enable application hosting (of a limited form, as we've

Re: Compaction daemon changes

Plan sounds reasonable to me also. > On 6 Sep 2019, at 15:15, Paul Davis wrote: > > Seems mostly reasonable. The only thing I'd add is that if we're > looking to implement #1 I'd assume we'd reuse or at least rework the > old compaction daemon code which makes me think that #3 would be >

Re: [PROPOSAL] Deprecate several mailing lists

+1 > On 1 Aug 2019, at 21:14, Paul Davis wrote: > > +1 > > On Thu, Aug 1, 2019 at 1:31 PM Nick Vatamaniuc wrote: >> >> +1 >> >> On Thu, Aug 1, 2019 at 1:08 PM Garren Smith wrote: >> >>> +1 >>> >>> On Thu, Aug 1, 2019 at 6:52 PM Jan Lehnardt wrote: >>> +1 Cheers Jan

Re: CouchDB and future

or workovers of CouchDB >>> without concern as to: >>> - what market is targeted >>> - what competitive position in this market is being targeted >>> - how to build on the existing user base for future success >>> >>> The latter point is crucial in

Re: CouchDB and future

the chasm". > > Chitans reflections on how to serve markets in need of new solutions is the > kind of marketing discussion that CouchDB would benefit greatly from inviting. > > johs > >> On 7 Jul 2019, at 19:55, Robert Samuel Newson wrote: >> >&

Re: CouchDB and future

Hi, The main (current) difficulties in running CouchDB on embedded devices is running erlang there coupled with our clustering stack. To scale everything down to fit within the typical constraints of an embedded device requires effort, I don’t think couch “just works” there. The future

Re: [VOTE] amend the bylaws

+1 also, though there’s a single grammar point to address that I noted in the github diff thingy. B. > On 1 Jul 2019, at 18:01, Paul Davis wrote: > > +1 > > Also for others fighting GitHub's side scrolly thing, this article > made review significantly easier: > >

Re: Design doc index switching

we’d only allow a delete, which would delete the new index also. B. > On 17 May 2019, at 10:59, Jan Lehnardt wrote: > > > >> On 16. May 2019, at 23:03, Robert Samuel Newson wrote: >> >> I suggest an alternative; the new design document could include the _id of >

Re: Design doc index switching

I suggest an alternative; the new design document could include the _id of design document it’s replacing (“_replaces”:”_design/foo”). On completion of the view build of the new design document, CouchDB itself updates the named _id to the same content as the new design document (strictly, only

Re: [DISCUSS] Improve load shedding by enforcing timeouts throughout stack

gt; > https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/408 > > > On Thu, Apr 18, 2019 at 10:37 AM Robert Newson wrote: > >> 503 imo. >> >> -- >> Robert Samuel Newson >> rnew...@apache.org >> >> On Thu, 18 Apr 2019, at 18:24, Adam Koc

Re: [DISCUSS] Session token invalidation

I think the blacklist idea is a non-starter because of the storage overhead. However I do agree that we should end the auto extension of session cookies. You should get exactly whatever the configured duration is and no more. When that cookie expires, or sooner if you’re smart, you can request

Re: [DISCUSS] Per-doc access control

Hi, It’s sounds like we require a separate flag as to whether any given username or role may appear in such an informative 403 message. That is, wherever we sa that X is granted access, we have an optional flag on X to say if we can disclose its right of access to others, defaulting to false

Re: [DISCUSS] : things we need to solve/decide : storing JSON documents

become an inutile obfuscation]. > On 19 Feb 2019, at 21:39, Robert Samuel Newson wrote: > > Interesting suggestion, obviously the details might get the wrong kind of fun. > > Somewhere above I suggested this would be something we could change over time > and even use di

Re: [DISCUSS] Proposed Bylaws changes

I think such a > safeguard is important for our community. I also feel it would > be meaningless to push through an RFC without community support. > But our current bylaws would make this very straightforward. > Why not put in this "backstop?" > > -Joan > >

Re: [DISCUSS] Proposed Bylaws changes

I am +1 on the RFC’s and -1 on the "not directly affiliated with the proposer's employer” item. B. > On 13 Feb 2019, at 11:13, Jan Lehnardt wrote: > > Sounds fantastic, thanks too for the additional context! I’d love for us to > lead the way here (yet again). > > Best > Jan > — > >> On 12.

Re: # [DISCUSS] : things we need to solve/decide : storage of edit conflicts

nly the content of the edit that is being attempted >> (i.e., it does not need to read the current version of the document itself). >> >> So, I’d propose a separate subspace (maybe “_meta”?) for the revision trees, >> with keys and values that look like >> >&

Re: [DISCUSS] : things we need to solve/decide : storing JSON documents

Hi, Yes. The value (in the foundationdb sense) will always be the terminal value (string, number, boolean, null) and so the key has to be the path to that, including special delimiters for object and array boundaries (what fdb calls ’the tuple layer’). I’d also like to see more effort into

Re: [DISCUSS] CouchDB Roadmap

Hi, An excellent summary, I agree on almost all points. Aggregate functions in Mango will need a plan that we can carry forward to fdb couchdb. As noted in my opening email, the current aggregate functionality (“reduce”) in couchdb is the main piece that we don’t have a solution to with fdb

Re: [DISCUSS] Rebase CouchDB on top of FoundationDB

figure out yet how to compress json_path. > > I'll send what I have so far into separate thread (when it would be started). > > Best regards, > iilyak > > > On 2019/01/24 12:46:14, Michael Fair wrote: >> On Thu, Jan 24, 2019 at 2:11 AM Robert Samuel Ne

Re: [DISCUSS] FoundationDB is network available with no security?

Hi, The expectation is as the FDB docs say, it will be essential to provide perimeter security around your foundationdb cluster, you should not accept inbound connections to it from the outside world. It will be appropriate to allow inbound connections to the CouchDB port though, as that is

Re: [DISCUSS] Rebase CouchDB on top of FoundationDB

, at 12:46, Michael Fair wrote: > On Thu, Jan 24, 2019 at 2:11 AM Robert Samuel Newson > wrote: > >> >> We’d expand each document into a series of key-value pairs, where the key >> is the full path into the object and the value is the scalar value. E.g, >> >

Re: [DISCUSS] Rebase CouchDB on top of FoundationDB

Hi, Absolutely agree. While strictly orthogonal, document level access has been a wishlist item for a lot of users for a very long time. The main problem is how it interacts with (i.e, breaks) replication. That said, Jan is working on per-document level access now (pre-FoundationDB) based on

Re: [DISCUSS] Rebase CouchDB on top of FoundationDB

with the IBM team leave things to >>> be desired. Specifically, the Apache CouchDB community is frequently >>> not involved in design discussions around new features. Those happen >>> inside IBM and we “only” get a PR that then goes through the regular &

Re: [DISCUSS] Rebase CouchDB on top of FoundationDB

Hi, We’d expand each document into a series of key-value pairs, where the key is the full path into the object and the value is the scalar value. E.g, {“foo”: 12, “bar”, {“baz”: 13}} Would be foo => 12 bar.baz => 13 With some suitable prefix to denote database name and document id. If the

[DISCUSS] Rebase CouchDB on top of FoundationDB

Hi, CouchDB 2.0 introduced clustering; the ability to scale a single database across multiple nodes, increasing both the maximum size of a database and adding native fault-tolerance. This welcome and considerable step forward was not without its trade-offs. In the years since 2.0 was released,

Re: [PROPOSAL] Change the minimum supported Erlang version to OTP 19

+1 > On 20 Dec 2018, at 08:55, Jay Doane wrote: > > Currently, CouchDB requires at least OTP 17 or later to build and run > [1][2]. However, recent work undertaken to eliminate compiler warnings > [3][4] has highlighted the additional effort needed to continue to support > older Erlang

Re: [PROPOSAL] Officially deprecate CouchDB 1.x.

> I don't want to see branched development on 1.x that adds new > 1.x-only features, or back ports of major new 2.x functionality > like Mango or clustering. I agree. Any future couchdb 1.x release will be security and bug fixes only. Not new features, not backports. B. > On 7 Jul 2018, at

Re: [PROPOSAL] Officially deprecate CouchDB 1.x.

+1 I am also for the proposal to officially deprecate couchdb 1.x. I would not want to see back-porting or new feature work in 1.x even if a theoretical 3 person team were to materialise. Of course any such team that does appear could fork couchdb 1.x and work on it independently (the only

Re: [PROPOSAL] Flexible replicator client authentication and session support

+1, long overdue enhancement. I think we should drop oauth 1.0 support. besides that the proposal looks good. B. > On 7 Feb 2018, at 19:37, Nick Vatamaniuc wrote: > > Hello everyone, > > I'd like to present a proposal to add session cookie support to the > replicator. >

Re: [ANNOUNCE] Nick Vatamaniuc joins the PMC

Congratulations Nick, well deserved, and welcome aboard! B. > On 12 Nov 2017, at 03:39, Paul Davis wrote: > > Hooray and welcome, Nick! > > > On Sat, Nov 11, 2017 at 2:45 PM Joan Touzet wrote: > >> Congratulations! Welcome, Nick! >> >> -

Re: [DISCUSSION] Disallow all merges of PRs to master that cause tests to fail

+1 > On 16 Aug 2017, at 15:55, Paul Davis wrote: > > On Wed, Aug 16, 2017 at 1:46 AM, Joan Touzet wrote: >> Hi committers, >> >> I'd like to propose a change to our policy on version control, namely >> that no check-ins be allowed on the master

Re: [ANNOUNCE] Apache CouchDB 2.1.0 released

Thanks to everyone for the amazing efforts exerted to get here but a big and special thanks to Joan Touzet who made it her mission to get this done and succeeded. Best, B. > On 7 Aug 2017, at 19:09, Joan Touzet wrote: > > Dear community, > > Apache CouchDB 2.1.0 has been

Re: [PROPOSAL] Include replication scheduler in 2.1

+1. > On 16 Jul 2017, at 22:14, Joan Touzet wrote: > > Hi all, > > *Per the CouchDB bylaws, this is a concrete proposal that will default > to lazy consensus in 72 hours (2017.07.19 ~21:00).* > > As we approach release candidates for v2.1 (see next email), we have one >

Re: [PROPOSAL] Getting 2.1 out the door (was: Test Suite Stabilization)

On replication scheduler, I think we should stick to the plan and keep it out of 2.1. I'm so happy to hear there's lots of interest in it, though. The main part of getting 2.1 out is all this work to fix tests and release pipeline, so a 2.2 with the scheduler should follow swiftly behind 2.1.

Re: [ANNOUNCE] Glynn Bird elected as CouchDB committer

'Bout time. Welcome! > On 31 May 2017, at 12:48, Brad Noble wrote: > > Feature request: a Glynn Bird replicator > > Congrats, Glynn! > > > Brad Noble > Developer Advocacy > https://medium.com/ibm-watson-data-lab > br...@us.ibm.com > > > Jan

Re: CouchDB 2.0 and "Intuitive HTTP/JSON API and designed for Reliability" for couchapps

ok. your couch log should have a stack trace associated with that 2053811356 value. can you dig it out please? > On 23 May 2017, at 21:43, Johs Ensby wrote: > > 2053811356

Re: CouchDB 2.0 and "Intuitive HTTP/JSON API and designed for Reliability" for couchapps

we're going to need some more information than just "shows a red GET in the inspector" to diagnose this one. Does a curl request work reliably for these attachments? B. > On 23 May 2017, at 11:47, Johs Ensby wrote: > > Hi, > we have been using Couch 1.6 with a patch for the

Re: Truncated response when POST a _changes query

0 >> >> - We do not have any conflict version of the database in the system. >> >> - We have collected the CouchDB logs and Wireshark traces from the >> failing and passing cases (with delay while writing request body) and >> uploaded to >> https:/

Re: [Lazy Consensus] Move from JIRA to GitHub Issues

nice +1 :) > On 17 May 2017, at 22:32, Eli Stevens (Gmail) wrote: > > As a user and occasional bug reporter, I welcome the change. > > Searching for existing issues in JIRA was painful, mostly due to > feeling like I had to repeat myself in saying that I wasn't interested

Re: 2.1

+1 > On 11 May 2017, at 18:47, Nick Vatamaniuc wrote: > > +1 > > On Thu, May 11, 2017 at 1:41 PM, Jan Lehnardt wrote: > >> Hi all, >> >> we should get CouchDB 2.1 out soon and the test suite situation is a >> somewhat annoying blocker, so I’m proposing

Re: Descending replication

Hi, I agree this would be a great option, even a better default. B. > On 4 May 2017, at 14:21, Johannes J. Schmidt wrote: > > Hi! > > I'm cross posting this issue from the PouchDB project: > https://github.com/pouchdb/pouchdb/issues/6480 > > > # Descending

Re: Truncated response when POST a _changes query

Agree with Joan, the most important thing is the log files. If couchdb can send an error in the response, it will (a 413 or 404, etc, etc). But if we've already started the response and _then_ encounter an error, we can't send any useful information in the response, we have to close the

Re: RFC CouchDB Slack channel

I'm equivocal on the proposal (and I'm a long-time user of IRC and Slack) so I won't vote ... yet. Instead of voting, perhaps I can suggest a path forward? We (PMC) will first evaluate the available privacy controls of the free tier and determine if an appropriate balance can be struck. I

CouchDB Summit Notes

Hi, A group of couchdb folks got together recently for a 3 day session (Feb 10, 11, 12) to discuss the couchdb roadmap. In attendance; Russell Branca, Paul Davis, Dale Harvey, Adam Kocoloski, Nolan Lawson, Jan Lehnardt, Gregor Martynus, Robert Newson, Garren Smith, Joan Touzet. We took turns

  1   2   3   >