Re: [VOTE] Release Apache CouchDB 3.3.3

+1 checksum: match sig: ok make check: pass make release: ok fauxton verify installation: pass os: macos 14.1.2 (23B92) erlang: 24.3.4.11 elixir: 1.14.3-otp-24 python: 3.11.6 spidermonkey: 91 > On 1 Dec 2023, at 20:28, Jay Doane wrote: > > signature: ok > checksum: match > make check: pass >

Out of disk handler proposal

Hi All, out of disk handler I propose to enhance CouchDB to monitor disk occupancy and react automatically as free space becomes scarce. I've written a working prototype at: https://github.com/apache/couchdb/compare/main...out-of-disk-handler The `diskmon` application is part of Erlang/OTP

Re: [DISCUSS] Make Erlang 24 our minimum supported version

+1 from me. Since the binary builds include erlang/otp we aren't restrained by which version of erlang each distro/platform currently uses. Anyone that wants to build from source can install erlang 24 by other means. B. > On 27 Apr 2023, at 00:21, Nick Vatamaniuc wrote: > > What do we think

Re: [VOTE] Release Apache CouchDB 3.3.1-RC2

+1 Sig: valid Checksums: match Make check: passes Given the bug in 3.3.0, I checked that multiple replications work manually. macOS 13.1, sm 91, erlang 23, elixir 1.13.4 > On 9 Jan 2023, at 14:56, Jan Lehnardt wrote: > > +1 > > macOS arm64 and x86_64, Erlang 25, SM91. > > Best > Jan > — >

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

+1 MacOS Ventura 13.1, erlang 23.3.4.14, elixir 1.13.4-otp-23 (both via asdf). Sha256: ok Sha512: ok Sig: ok Make check: pass Make release: works Fauxton verify installation: pass Excellent work, everyone. So much in this release! B. > On 26 Dec 2022, at 20:16, Nick Vatamaniuc wrote: > > My

Re: [DISCUSSION] Make Erlang 23 the minimum supported distribution

+1 > On 13 Jun 2022, at 21:30, Ilya Khlopotov wrote: > > It would be great to move to 23. It has quite a few interesting features, > which we could use. > > Also as Nick said it would make switching to rebar3 easier. > > +1 to the proposal > > Best regards, > iilyak > > On 2022/06/13

Re: [DISCUSSION] Rename 3.x branch to main and include docs in the main repo

+1. It's time. B. > On 2 Jun 2022, at 20:40, Nick Vatamaniuc wrote: > > Hi everyone, > > In a #dev slack thread we were discussing improvements to how we tag > our documentation repo. There were two proposals to simplify the > development and release process, and we wanted to see what the

Re: Native Encryption

te of the file. B. > On 19 May 2022, at 11:17, Will Young wrote: > > On Wed, 18 May 2022, 19:31 Robert Newson, wrote: > >> Hi Will, >> >> I still don't see how public/private encryption helps. It seems the >> private keys in your idea(s) are needed in all the

Re: Native Encryption

Hi Will, I still don't see how public/private encryption helps. It seems the private keys in your idea(s) are needed in all the same places and for the same duration as the secret keys in mine. I think it's clear, though, that I didn't fully comprehend your post. I can at least see that my

Re: Native Encryption

Hi Will, Thanks for your post and for spending significant time thinking about my proposal. An important aspect of my proposed patch has, I think, been overlooked or under-examined. There is no essential need for the wrapping keys to ever be present in Erlang memory or, indeed, ever to leave

Native Encryption

All, One feature we built on main (aka 4.x) was native support for encrypted databases. As the foundationdb/4.x work is largely halted now I thought I'd scratch a personal itch and try to bring this feature to 3.x. I've posted a draft pull request at https://github.com/apache/couchdb/pull/4019

Re: [ANNOUNCE] Will Young elected as CouchDB committer

Congrats Will! Welcome aboard. B. > On 19 Apr 2022, at 08:36, Jan Lehnardt wrote: > > Dear community, > > I am pleased to announce that the CouchDB Project Management Committee has > elected Will Young as a CouchDB committer. > >Apache ID: wyoung > >Slack nick: Will Young > >

Re: Important update on couchdb's foundationdb work

ou. > > -- > Chintan Mishra > > On 13/03/22 17:09, Robert Newson wrote: >> Thank you for this feedback. >> I think it’s reasonable to worry about tying CouchDB to FoundationDB for >> some of the reasons you mentioned, but not all of them. We did worry, at

Re: Important update on couchdb's foundationdb work

e got them all >> now, or if there are theoretical limits to how far we can take this given >> our consistency model, but it’d be worth spending some time on at least >> getting rid of all rewind-to-zero cases. >> >> * * * >> >> I’m also looking

Re: Important update on couchdb's foundationdb work

at I see: > > 1. Follow IBM in abandoning FDB-Couch, refocus all effort on Erlang-Couch > (3.x). > > 2. Take FDB-Couch development over fully, come up with a story for how > FDB-Couch and Erlang-Couch can coexist and when users should choose which one. > > 3. Hand over the FDB-Co

Important update on couchdb's foundationdb work

for their efforts. As the Project Management Committee for the CouchDB project, we are now asking the developer community how we’d like to proceed in light of this new information. Regards, Robert Newson Apache CouchDB PMC

Re: [PROPOSAL] Drop support for Ubuntu 16.04

+1 > On 15 Jan 2022, at 06:26, Nick V wrote: > > That sounds great. +1 to drop Ubuntu 16.04 > > -Nick > >> On Jan 14, 2022, at 22:41, Adam Kocoloski wrote: >> >> Hi, I propose that we remove Ubuntu 16.04 (Xenial Xerus) from the CI matrix >> and binary package generation systems. >> >>

Re: [DISCUSS] Handle libicu upgrades better

Noting that the upgrade channel for views was misconceived (by me) as there is no version number in the header for them. You’d need to add it. B. > On 18 Nov 2021, at 07:12, Nick Vatamaniuc wrote: > > Thinking more about this issue I wonder if we can avoid resetting and > rebuilding

Re: [VOTE] Release Apache CouchDB 3.1.2

+1 Sigs, checksums and 'make check' passed for me. macOS 11.6, erlang 22, elixir 1.9.4. > On 27 Sep 2021, at 13:53, Nick Vatamaniuc wrote: > > Dear community, > > I would like to propose that we release Apache CouchDB 3.1.2 > > Changes since 3.1.1 > > >

Re: Reformat src files with `erlfmt` on `main`

ML discussion which hook manager to use? >> >> Another option is to update configure or rebar.config.script to place >> files (or links) in `.git/hooks/pre-commit`. >> >> Best regards, >> iilyak >> >> On 2021/05/21 12:25:53, Robert Newson wrote: >>

Re: Reformat src files with `erlfmt` on `main`

e’s no backsliding. Can it also be set up as a local git hook etc? B. > On 21 May 2021, at 12:46, Bessenyei Balázs Donát wrote: > > Hi All, > > I believe I've only seen +>=0s so far so I intend to (in the following order): > * wait for an ok from @Robert Newson and @Paul J. Davis

Re: [DISCUSSION] Clean up non-functioning applications from main

+1 to all the proposed cuts. I’m keen to see couch_server.erl itself go, so its remaining uses need new homes (couch_passwords an obvious choice for the hashing referred to, etc). I’m inferring that neither purge and global_changes work on main anyway, but they can still be called and will

Re: Removing "node" field from replicator "/_scheduler/{jobs | docs}"

bric] > fdb_directory config. Both clusters were sharing the same FDB cluster > underneath). > > Cheers, > -Nick > > On Fri, Apr 2, 2021 at 6:00 PM Bessenyei Balázs Donát > wrote: >> >> I support removing obsolete fields from responses. >> I also suppor

Re: Removing "node" field from replicator "/_scheduler/{jobs | docs}"

+1 to removing “node” on main (but not 3.x branch). B. > On 2 Apr 2021, at 21:11, Ilya Khlopotov wrote: > > Hi, > > In FDB world there wouldn't be erlang mesh as far as I can tell. In this > situation the `node` field in the response from `/_scheduler/jobs` and > `/_scheduler/docs`

Re: [VOTE] Set a finite default for max_attachment_size

Hi, I think a gigabyte is _very_ generous given our experience of this feature in practice. In 4.x attachment size will necessarily be much more restrictive, so it seems prudent to move toward that limit. I don’t think many folks (hopefully no one!) is routinely inserting attachments over 1

Re: [VOTE] Set a finite default for max_attachment_size

+1 > On 28 Jan 2021, at 05:46, Bessenyei Balázs Donát wrote: > > Hi All, > > In https://github.com/apache/couchdb/pull/3347 I'm proposing to set a > finite default for max_attachment_size . > The PR is approved, but as per Ilya's request, I'd like to call for a > lazy majority vote here. > The

Re: [DISCUSS] Removing erlang 19 support

chosen Erlang release is in part influenced by CouchDB’s lack of support for later versions and requirement of compatible with older releases, which now appears illusory. B. > On 22 Jan 2021, at 21:19, Joan Touzet wrote: > > On 22/01/2021 15:48, Robert Newson wrote: >> I’m +1 on

Re: [DISCUSS] Removing erlang 19 support

I’m +1 on dropping Erlang 19 support. Erlang is now on major release 23. I’d further advocate a general policy of supporting only the most recent 2 or 3 major releases of Erlang/OTP. The main (I think only?) reason to keep compatibility so far back is because of the versions supported by some

[ANNOUNCE] Bessenyei Balázs Donát elected as CouchDB committer

. This election was made in recognition of Donát's commitment to the project. We mean this in the sense of being loyal to the project and its interests. Please join me in extending a warm welcome to Donát! On behalf of the CouchDB PMC, Robert Newson

Re: [VOTE] couchdb 4.0 transaction semantics

ds as >>>> well, as described in the thread >>>> >>>> Cheers, >>>> -Nick >>>> >>>>> On Jan 8, 2021, at 17:12, Joan Touzet wrote: >>>>> >>>>> Thanks, then it's a solid +1 from me. >>>>

Re: [VOTE] couchdb 4.0 transaction semantics

n Jan 8, 2021, at 17:12, Joan Touzet wrote: >> >> Thanks, then it's a solid +1 from me. >> >> -Joan >> >>> On 2021-01-08 4:13 p.m., Robert Newson wrote: >>> You are probably thinking of a possible “group commit”. That is anticipated >>> and

Re: [VOTE] couchdb 4.0 transaction semantics

> +1. > > This is for now I presume, as I thought that there was feeling about > relaxing this restriction somewhat for the 5.0 timeframe? Memory's dim. > > -Joan > > On 07/01/2021 06:00, Robert Newson wrote: >> Hi, >> >> Following on from the discus

Re: [VOTE] couchdb 4.0 transaction semantics

+1 > On 7 Jan 2021, at 11:00, Robert Newson wrote: > > Hi, > > Following on from the discussion at > https://lists.apache.org/thread.html/rac6c90c4ae03dc055c7e8be6eca1c1e173cf2f98d2afe6d018e62d29%40%3Cdev.couchdb.apache.org%3E > > <https://l

[VOTE] couchdb 4.0 transaction semantics

Hi, Following on from the discussion at https://lists.apache.org/thread.html/rac6c90c4ae03dc055c7e8be6eca1c1e173cf2f98d2afe6d018e62d29%40%3Cdev.couchdb.apache.org%3E

Re: [DISCUSS] couchdb 4.0 transactional semantics

Apologies for resurrecting this thread after so long. I’ve looked over the thread again today and it seems there is general consensus on the desired semantics. I will start a vote thread. B. > On 24 Jul 2020, at 18:27, Nick Vatamaniuc wrote: > > Great discussion everyone! > > For normal

Re: Jenkins issues, looking for committer volunteer(s)

+1 -- Robert Samuel Newson rnew...@apache.org On Tue, 15 Sep 2020, at 09:18, Jan Lehnardt wrote: > > > > On 15. Sep 2020, at 04:09, Joan Touzet wrote: > > > > Paul informs me that IBM have discontinued all Power platform hosting at > > the level that suits us. He is following up with

Re: Preparing 3.1.1 release

Nice -- Robert Samuel Newson rnew...@apache.org On Tue, 1 Sep 2020, at 16:24, Jan Lehnardt wrote: > This PR by my coworker Jacoba should address this issue satisfactorily: > >https://github.com/apache/couchdb-fauxton/pull/1292 > > Best > Jan > — > > > On 27. Aug 2020, at 11:41, Jan

Re: [DISCUSS] Reduce on FDB take 3

ithub.com/apache/couchdb/compare/prototype/fdb-layer...prototype/fdb-layer-ebtree-views > >> > >> Its currently passing all tests in `couch_views_map_test.erl` but is > >> failing on other suites. I only did a quick skim on the failures but > >> they all look super

Re: [DISCUSS] Reduce on FDB take 3

> you happy with that? > > Cheers > Garren > > On Fri, Jul 24, 2020 at 3:48 PM Robert Newson wrote: > > > Hi, > > > > It’s not as unknown as you think but certainly we need empirical data to > > guide us on the reduce side. I’m also fine with continuing with the &

Re: [DISCUSS] Reduce on FDB take 3

Hi, It’s not as unknown as you think but certainly we need empirical data to guide us on the reduce side. I’m also fine with continuing with the map-only code as it stands today until such time as we demonstrate ebtree meets or exceeds our needs (and I freely accept the possibility that it

Re: [DISCUSS] Reduce on FDB take 3

Thank you for those kind words. -- Robert Samuel Newson rnew...@apache.org On Tue, 21 Jul 2020, at 13:45, Jan Lehnardt wrote: > Heya Garren an Bob, > > this looks really nice. I remember when this was a twinkle in our > planning eyes. Seeing the full thing realised is very very cool. > >

Re: [DISCUSS] couchdb 4.0 transactional semantics

Thanks Jan I would prefer not to have the configuration switch, instead remove what we don’t want. As you said there’ll be a 3 / 4 split for a while (and not just for this reason). -- Robert Samuel Newson rnew...@apache.org On Wed, 15 Jul 2020, at 14:46, Jan Lehnardt wrote: > > > On

Re: [DISCUSS] length restrictions in 4.0

I still don’t understand how the internal shard database name format has any bearing on our public interface, 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

Re: [DISCUSS] Streaming API in CouchDB 4.0

cursor has established meaning in other databases and ours would not be very close to them. I don’t think it’s a good idea. B. > On 23 Apr 2020, at 11:50, Ilya Khlopotov wrote: > >  >> >> The best I could come up with is replacing page with >> cursor - {db}/_all_docs/cursor or possibly

Re: [DISCUSS] Mango indexes on FDB

No, 425 is something specific A 503 Service Unavailable seems the only suitable standard code. B. > On 24 Mar 2020, at 08:48, Glynn Bird wrote: > > If a user didn't specify the index they wanted to use, leaving the choice > of index up to CouchDB, I would expect Couch would ignore the

Re: FDB: Map index key/value limits

Option A matches our behaviour for other (persistent) errors during indexing and gets my vote. Surfacing view build errors (option C) is certainly better but is obviously more work. > On 16 Jan 2020, at 16:09, Adam Kocoloski wrote: > > Right. I sort of assumed an additional endpoint,

Re: CouchDB 3.0 Update - Dec 3rd

Hi, I’m fine with a release either side of Christmas but I agree with Joan’s point. I suggest a compromise of a code freeze. Only fixes for 3.0 to be merged until the new year then do the release dance. > On 4 Dec 2019, at 14:45, support-tiger wrote: > > fyi: Every year Ruby releases a new

Re: Move ken / smoosh / ioq applications in-tree

+1 B. > On 22 Nov 2019, at 04:33, Adam Kocoloski wrote: > > Hi all, > > Any complaints about moving these apps into the main CouchDB repo? None of > them have any utility outside of CouchDB. Cheers, > > Adam

Re: Batch mode options for CouchDB 4.0

I am fine with returning 202 even though we blocked to complete the request. B. > On 29 Oct 2019, at 10:24, Mike Rhodes wrote: > > There are a two things I'd like to break down here: > > 1. The non-functional behaviour of the API is changing. What was hopefully a > short request could now

Re: [DISCUSS] [PROPOSAL] Accept donation of the IBM Cloudant Weather Report diagnostic tool?

I’m for the proposal and am confident IBM will apply release custodian under the ASLv2 if the community is in favour of the the proposal. B. > On 14 Aug 2019, at 07:19, Jay Doane wrote: > > In the interest of making CouchDB 3.0 "the best CouchDB Classic possible", > I'd like to discuss

Re: [VOTE] Adopt FoundationDB

+1 B. > On 30 Jul 2019, at 09:51, Garren Smith wrote: > > +1 > >> On Tue, Jul 30, 2019 at 10:27 AM Jan Lehnardt wrote: >> >> Dear CouchDB developers, >> >> This vote decides whether the CouchDB project accepts the proposal[1] >> to switch our underlying storage and distributed systems

Re: CouchDb Rewrite/Fork

That’s valuable feedback thank you. Best of luck with your new project and a gentle reminder that you may not call it CouchDB. B. > On 10 Jul 2019, at 00:07, Reddy B. wrote: > > Hi all, > > I've checked the recent discussions and apparently July is the "vision month" > lol. Hopefully

Re: CouchDB and future

Hi, CouchDB 1.x is no longer supported, even for security updates. CouchDB 4.0, the one with foundationdb, will reinstate a few couchdb 1.x semantics, particularly in the _changes response. B. > On 8 Jul 2019, at 16:24, Chintan Mishra wrote: > > Interesting. I started using CouchDB since

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

gt; > > > > > Any reason 408 would be undesirable? > > > > > > 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. >

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

503 imo. -- Robert Samuel Newson rnew...@apache.org On Thu, 18 Apr 2019, at 18:24, Adam Kocoloski wrote: > Yes, we should. Currently it’s a 500, maybe there’s something more > appropriate: > >

Re: [DISCUSS] FDB and CouchDB replication

As long as any given replicator node can grab as much work as it can handle, It doesn't need to be 'fair' in the way we currently do it. The notion of an 'owner' node drops away imo. As nick mentions, the fun part is recognising when jobs become unowned due to a resource failure somewhere but

Re: [DISCUSS] Statistics maintenance in FoundationDB

Hi, I agree with all of this. On "sizes", we should clean up the various places that the different sizes are reported. I suggest we stick with just the "sizes" object, which will have two items, 'external' which will be jiffy's estimate of the body as json plus the length of all attachments

Re: [DISCUSS] Implementing _all_docs on FoundationDB

Hi, Thanks for pushing forward, and I owe feedback on other threads you've started. Rather feebly, I'm just agreeing with you. option 3 for include_docs=false and option 1 for include_docs=true sounds ideal. both flavours are very common so it makes sense to build a solution for each. At a

Re: FoundationDB & Multi tenancy model

Hi, Firstly, CouchDB today does not have multi-tenancy as a feature. Cloudant does and achieves this by inserting the tenant's name as a prefix on the database name (so "rnewson/db1" is a different database to "sleroux/db1"), with appropriate stripping of the prefix in various responses. I

Re: [DISCUSS] : things we need to solve/decide : changes feed

+1 to both changes, will echo that in the PR. -- Robert Samuel Newson rnew...@apache.org On Wed, 6 Mar 2019, at 00:04, Adam Kocoloski wrote: > Dredging this thread back up with an eye towards moving to an RFC … > > I was reading through the FoundationDB Record Layer preprint[1] a few >

Re: [VOTE] Bylaws change: Establish a Qualified Lazy Majority vote type for the RFC process (revised)

-1 for the following reason: "https://apache.org/foundation/how-it-works.html#hats INDIVIDUALS COMPOSE THE ASF All of the ASF including the board, the other officers, the committers, and the members, are participating as individuals. That is one strength of the ASF, affiliations do not cloud

Re: [VOTE] Bylaws change: Establish a Request For Comments (RFC) process for major new contribution (revised)

+1 -- Robert Samuel Newson rnew...@apache.org On Tue, 5 Mar 2019, at 20:18, Joan Touzet wrote: > (Revised: The Reply-To field on the last email was incorrect. I am > also including the diff of the proposed changes to this email per > request.) > > > > PMC Members, > > This

Re: Maintainig two codebases

Hi, The first decision is to what extent we are supporting the "old" version (once the new one exists, of course). I think it would be limited to security fixes. If so, this is exactly the same as when we released 1.2, 1.3, and so on. Master is always latest (FDB, in this case) and there are

Re: [DISCUSS] Attachment support in CouchDB with FDB

ximum attachment size for the native > provider — as I understand things the FDB transaction size includes > both keys and values, so our effective attachment size limit will be > smaller. > > Adam > > > On Feb 28, 2019, at 6:21 AM, Robert Newson wrote: > > >

Re: [DISCUSS] Attachment support in CouchDB with FDB

easonably popular feature. > > Best > Jan > — > >> On 28. Feb 2019, at 11:22, Robert Newson wrote: >> >> Hi All, >> >> We've not yet discussed attachments in terms of the foundationdb work so >> here's where we do that. >> >> To

[DISCUSS] Attachment support in CouchDB with FDB

Hi All, We've not yet discussed attachments in terms of the foundationdb work so here's where we do that. Today, CouchDB allows you to store large binary values, stored as a series of much smaller chunks. These "attachments" cannot be indexed, they can only be sent and received (you can fetch

Re: [DISCUSS] Per-doc access control

Not to pile on here but "Once you read your available docs into your DB, you can grant yourself write privileges to every document there." does seem to miss the mark. All replication is doing is making a copy of data you have access to. You can modify your own copy as you please, it doesn't

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

e of key prefix > compression. That would be my main reason to acquiesce and throw away > all the document structure. > > Adam > > > On Feb 19, 2019, at 12:04 PM, Robert Newson wrote: > > > > I like the idea that we'd reuse the same pattern (but perhaps not

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

.erl > > > > * It removes the need to explain the max exploded path length limitation to > > customers. > > > > Cheers, > > -Nick > > > > > > On Tue, Feb 19, 2019 at 11:18 AM Robert Newson wrote: > > > >> Hi, > &

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

. -- Robert Samuel Newson rnew...@apache.org On Mon, 4 Feb 2019, at 19:59, Robert Newson wrote: > I've been remiss here in not posting the data model ideas that IBM > worked up while we were thinking about using FoundationDB so I'm posting > it now. This is Adam' Kocoloski's original work,

Re: [VOTE] Release Apache CouchDB 2.3.1 RC2

now it exists and is the right value :) -- Robert Samuel Newson rnew...@apache.org On Tue, 19 Feb 2019, at 14:30, Robert Newson wrote: > the sha256 file exists but is zero bytes long. > > -- > Robert Samuel Newson > rnew...@apache.org > > On Tue, 19 Feb 2019, a

Re: [VOTE] Release Apache CouchDB 2.3.1 RC2

the sha256 file exists but is zero bytes long. -- Robert Samuel Newson rnew...@apache.org On Tue, 19 Feb 2019, at 13:03, Jan Lehnardt wrote: > > > > On 19. Feb 2019, at 13:14, Robert Newson wrote: > > > > sha512 checksum - verified > > sha256 checksum -

Re: [VOTE] Release Apache CouchDB 2.3.1 RC2

sha512 checksum - verified sha256 checksum - missing signature - good eunit tests - pass js tests - crashes at delayed_commits.js with "test/javascript/tests/delayed_commits.js Error: Failed to execute HTTP request: Failed to connect to 127.0.0.1 port 15984: Connection refused" --

Re: [DISCUSS] Proposed Bylaws changes

https://apache.org/foundation/how-it-works.html#hats INDIVIDUALS COMPOSE THE ASF All of the ASF including the board, the other officers, the committers, and the members, are participating as individuals. That is one strength of the ASF, affiliations do not cloud the personal contributions.

Re: [DISCUSSION] Proposed new RFC process

Hi, I like the idea of RFC's and agree with Joan that they should help with the actual (and perceived) gaps in cooperation from large corporate vendors. I would like to see a mandatory "Security Considerations" section added to the template. Not every RFC will have anything to say on the

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

gt; > perspective, but they’re both operating on the same data model so easy > > enough to test the alternatives. The important bit is getting the > > revision-ish things to sort correctly. I think we can do that by generating > > something like > > > > revision-ish =

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

I've been remiss here in not posting the data model ideas that IBM worked up while we were thinking about using FoundationDB so I'm posting it now. This is Adam' Kocoloski's original work, I am just transcribing it, and this is the context that the folks from the IBM side came in with, for full

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

This one is quite tightly coupled to the other thread on data model, should we start much conversation here before that one gets closer to a solution? -- Robert Samuel Newson rnew...@apache.org On Mon, 4 Feb 2019, at 19:25, Ilya Khlopotov wrote: > This is a beginning of a discussion thread

Re: [DISCUSS] : things we need to solve/decide : changes feed

Let's not conflate two things here. The changes feed is just the documents in the database, including deleted ones, in the order they were last written. This is simple to do in FoundationDB and Adam already showed the solution using fdb's versionstamps. The talk of 'watcher' and 'subscriber'

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

I think we're deep in the weeds on this small aspect of the data model problem, and haven't touched other aspects yet. The numbers used in your example (1k of paths, 100 unique field names, 100 bytes for a value), where are they from? If they are not from some empirical data source, I don't see

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

Hi, The talk of crypto in the key space is extremely premature in my opinion. It it is the database's job (foundationdb's in this case) to map meaningful names to whatever it takes to efficiently store, index, and retrieve them. Obscuring every key with an expensive cryptographic operation

Re: [DISCUSS] Rebase CouchDB on top of FoundationDB

this are an impediment to its greater > success). > > Let me know if you'd like more detail on anything. :) > > Cheers, > Eli > > On Fri, Feb 1, 2019 at 9:29 AM Robert Newson wrote: > > > Hi, > > > > Avoiding unintended regressions is a high p

Re: [DISCUSS] Rebase CouchDB on top of FoundationDB

Hi, Avoiding unintended regressions is a high priority for the team and we will need to lean on the community here to keep us honest. I'd appreciate a summary of the capability regressions that affected you. The CouchDB PMC is interacting with the FoundationDB team now (you can see the

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

Hi, "rebasing is not just a politically correct way of saying that CouchDb is being retired" Emphatically, no. We see this is an evolution of CouchDB, delivering CouchDB 1.0 semantics around conflicts and changes feeds but in a way that scales better than CouchDB 2.0's approach. We intend to

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

y without shelling out to JS. > > It’s pretty obviously a big, meaty topic unto itself, one that needs > some careful thought and design. Also an awful lot of opportunity for > scope creep. But a good topic nonetheless. > > Adam > > > On Jan 31, 2019, at 12:05 P

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

00k chunks. thoughts? B -- Robert Newson b...@rsn.io On Thu, 31 Jan 2019, at 16:26, Adam Kocoloski wrote: > > > On Jan 31, 2019, at 1:47 AM, ermouth wrote: > > > >> As I don't see the 10k limitation as having significant merit > > > > Not sure it’s relevant h

Re: [DISCUSS] Rebase CouchDB on top of FoundationDB

group level reduces will be at least as efficient as today, I think. For arbitrary start/endkey reduce we might decide to not support them, or to support them the expensive way (without the benefit of precomputed intermediate values). B. -- Robert Newson rnew...@apache.org On Sun, 27 Jan

Re: [DISCUSS] Rebase CouchDB on top of FoundationDB

Hi, It’s only arbitrary start/end key of the reduce values we have no solution for yet . For map-only, we can and would supply arbitrary start/end key. More explicitly, it’s only _efficient_ reduce results that are lost, because we can’t store the intermediate reduce values on inner btree

Re: [DISCUSS] Rebase CouchDB on top of FoundationDB

gt;> with the database update. >>>> >>>> For those familiar with the CouchDB 2.0 architecture, the proposal is, >>> in effect, to change all the functions in fabric.erl so that they work >>> against a (possibly remote) FoundationDB cluster instead of the c

Re: Proposal: removing view changes code from mrview

working on it *right now*.) >>> >>> - Original Message - >>> From: "Eiri" >>> To: dev@couchdb.apache.org >>> Sent: Tuesday, April 3, 2018 8:15:21 AM >>> Subject: Proposal: removing view changes code from mrview >>>

Re: [PROPOSAL] Drop PDF / texinfo documentation builds

+1. Please use fire. > On 18 Mar 2017, at 17:44, Robert Kowalski wrote: > > good idea, +1 > >> On Sat, Mar 18, 2017 at 9:14 AM, Jan Lehnardt wrote: >> >> +1 >> >> Cheers >> Jan >> -- >> >>> On 18 Mar 2017, at 05:55, Joan Touzet wrote: >>>

Re: ransom note - couchdb exploit / privilege escalation ?

Hi Vivek, Thanks for the update and thanks for persevering. I agree with you on likely cause here. To your follow up question, it's not intentional that _users can be deleted, its more a side effect of admin privileges. CouchDB before 2.0 will create that db automatically if it's missing.

Re: ransom note - couchdb exploit / privilege escalation ?

A reminder that the security sensitive discussion with Vivek is happening elsewhere. We don't want to reveal any issue that might be found until we have a fix, if it turns out to be an avoidable fault in couchdb. The discussion of improved 3.0 defaults can continue here or in a new thread.

Re: CouchDB 2.0 as Snap

Make a separate systemd service for epmd and have the couch one depend on it. There is a parameter you can add to couch's vm.args file to prevent it even trying to start epmd. Sent from my iPhone > On 19 Sep 2016, at 22:47, Michael Hall wrote: > > Thanks to help from Jan

Re: Printing passwords in Couch log files?

100% agree that we shouldn't but it's hard to guarantee it never happens, hence the warning. Passwords are held in process state so we can authenticate to remote sources and targets while replicating. Crashes of those processes write state dumps to the log. We can do better but it will

Re: Adding a node to cluster

Ok, seems I've confused you. Couchdb replication occurs over http or https, as you know. The nodes in a couchdb 2.0 cluster do not communicate with each other over http. They use Erlang rpc. Erlang rpc can be configured for TLS encryption. It's in the Erlang faq and is fairly simple to set

Re: Can clustering be setup between nodes that only accept SSL connections?

Yes, couchdb can be configured that way but my recommendation is to put something like haproxy in front instead. The native ssl support in Erlang has a buggy history in my experience, though I believe 18.x is working quite nicely. Further, with couchdb 2.0, you'll want a round-robin loss

Re: local.d/*.ini are not read by couchdb 2.0 rc2?

I filed a ticket for it. It'll work before final 2.0 release. Sent from my iPhone > On 31 Jul 2016, at 22:48, Bian Ying wrote: > > Thanks for your response. > > Can this make into rc3 or rc4? It's important for us to have configurations > managed in local.d. > > - Ying > >>

Re: Mango full text search is immune to accented letters?

The backend of mango FT is Lucene and certainly handles accented characters. It all comes down to which analyser you are using. Sent from my iPhone > On 30 Jul 2016, at 13:17, Constantin Teodorescu wrote: > > Is Mango Full text indexer/search (or would it be) immune for

Re: CouchDB 2.0 blog series

onses to my initial requests for volunteers I’ve put >> together >> a tentative schedule for the series. I've also created issues in JIRA >> and if >> there aren't any objections, I'll be assigning these dates as the due >> dates. >> >> >> >&

  1   2   3   4   5   6   7   8   9   10   >