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

Another +1 to removing as much as possible and building back anything that we feel is appropriate for main. On Mon, Apr 12, 2021 at 1:31 PM Robert Newson wrote: > > +1 to all the proposed cuts. > > I’m keen to see couch_server.erl itself go, so its remaining uses need new > homes

Re: [VOTE] Set a finite default for max_attachment_size

+1 Default unlimited seems like an oversight regardless of what we change it to. On Mon, Feb 1, 2021 at 11:59 AM Eric Avdey wrote: > > Maybe I didn't express myself clear enough. Setting some finit default is not > a purpose, it's what you are doing and I'm asking what the reason for this >

Re: [VOTE] couchdb 4.0 transaction semantics

ges endpoint when in feed=continuous mode, > > that all data-bearing responses from CouchDB are constructed from a single, > > immutable snapshot of the database at the time of the request.” > > > > Paul Davis summarised the discussion in four bullet points, reiterated here

Re: [DISCUSS] Deprecate custom reduce functions

r 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 > >>>

Re: [PROPOSAL] Archiving git branches

+1 On Wed, Oct 7, 2020 at 5:11 PM Joan Touzet wrote: > > Hi there, > > I'd like to clean up our branches in git on the main couchdb repo. This > would involve deleting some of our obsolete branches, after tagging the > final revision on each branch. This way, we retain the history but the >

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

I'll create the branches on all of the appropriate repositories today and start looking at Jenkins requirements. I'll hold off on filing the infra ticket until tomorrow so that folks have time to double check my sanity. On Wed, Sep 16, 2020 at 10:50 AM Paul Davis wrote: > > Also, I

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

at 10:49 AM Paul Davis wrote: > > Right. I figure that's basically an ASF version of the `gh-pages` branch? > > On Wed, Sep 16, 2020 at 10:39 AM Joan Touzet wrote: > > > > > > On 16/09/2020 11:39, Paul Davis wrote: > > > On Wed, Sep

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

Right. I figure that's basically an ASF version of the `gh-pages` branch? On Wed, Sep 16, 2020 at 10:39 AM Joan Touzet wrote: > > > On 16/09/2020 11:39, Paul Davis wrote: > > On Wed, Sep 16, 2020 at 10:32 AM Joan Touzet wrote: > >> > >> > >> > >&g

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

On Wed, Sep 16, 2020 at 10:32 AM Joan Touzet wrote: > > > > On 16/09/2020 10:57, Paul Davis wrote: > > Hey all, > > > > Here's a list of all CouchDB related repositories with a few quick > > stats and my read on their status and requirements. Can I get some

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

trol system I used to use, called that > > branch "main": > > > > > > https://i.ibb.co/7bMDt3c/cc-ver-tree2.gif > > > > > > -Joan "yes, that's motif" Touzet > > > > > > > > > On 2020-09-09 11:40 a.m

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

I should have noted, for each of the `apache/couchdb-$repo` repositories my plan is to do a straight up copy of master -> main with zero other changes. Once that's done we'll need to update rebar.config.script but that should be all we need there. On Thu, Sep 10, 2020 at 3:11 PM Paul Da

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

hanks 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 probably the way to go. I've got a failing test in > >

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

a nice opportunity to take > the plunge. > > Best > Jan > — > > On 9. Sep 2020, at 17:40, Paul Davis wrote: > > > > Howdy Folks! > > > > Words matter. I've just started a thread on merging all of the > > FoundationDB work into mainline development and tho

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

://github.com/apache/couchdb/tree/prototype/fdb-layer-final-merge https://github.com/apache/couchdb/commit/873ccb4882f2e984c25f59ad0fd0a0677b9d4477 On Wed, Sep 9, 2020 at 10:29 AM Paul Davis wrote: > > Howdy folks! > > I've just gone through a rebase of `prototype/fdb-layer` against &

[DISCUSS] Rename default branch to `main`

Howdy Folks! Words matter. I've just started a thread on merging all of the FoundationDB work into mainline development and thought this would be a good time to bring up a separate discussion on renaming our default branch. Personally, I've got a few projects where I used `main` for the mainline

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

Howdy folks! I've just gone through a rebase of `prototype/fdb-layer` against master. Its not quite finished because the ebtree import went wrong during rebase due to a weirdness of the history. I have a PR up for the rebase into master for people to look at [1]. Although the more important

Re: [DISCUSS] Creating new deleted documents in CouchDB 4

Replication of deletions isn't affected due to the new_edits=false flag like you guessed. This is purely "interactively creating a new document that is deleted". Its a fairly minor edge case in that the document must not exist. Any other attempt to "revive" a deleted doc into a deleted state will

Re: object keys in couchdb 4

San, I don't remember that being a performance issue under consideration for the "exploded document" design that we had contemplated in particular, but I could see there being some concerns around it. However, we have not implemented that idea and instead just store documents in as few

Re: [DISCUSS] Reduce on FDB take 3

gt; This avoids the duplication that garren's idea of storing the reduces > > in ebtree was trying to avoid, but does so in all cases. This approach > > allows us to compare the performance of map queries against map-only and > > map-reduce indexes, it allows users to opt in or

Re: [DISCUSS] Reduce on FDB take 3

n Thu, Jul 23, 2020, 2:17 PM Robert Samuel Newson < > > > rnew...@apache.org> > > > > > >> wrote: > > > > > >> > > > > > >>> I (perhaps obviously) don't agree that I'm tying myself to old > > > Couch

Re: [DISCUSS] Reduce on FDB take 3

> I would like to keep ebtree to use just for the reduce index. Could you expand on your reasoning here, Garren? I haven't done any experiments on my own to understand if I'm missing something important. My initial reaction is to not diverge too far from the previous shape of the implementation

Re: [DISCUSS] Reduce on FDB take 3

Mostly chiming in just to say that I agree with Bob here. I haven't been paying the closest attention due to other things taking my time but when I've heard the discussion my assumption was that we'd be using a single ebtree instance per map/reduce index similar to how it works in CouchDB classic.

Re: [DISCUSS] couchdb 4.0 transactional semantics

>From what I'm reading it sounds like we have general consensus on a few things: 1. A single CouchDB API call should map to a single FDB transaction 2. We absolutely do not want to return a valid JSON response to any streaming API that hit a transaction boundary (because data loss/corruption) 3.

Re: Is everything ok on our Jenkins cluster?

2020, 20:23 Joan Touzet ha scritto: > > > On 18/06/2020 13:19, Alessio 'Blaster' Biancalana wrote: > > > Hi Joan, > > > Hi opened the infra bug, could you please check I've done everything > > > correctly? > > > > > > https://issues.apache.org/j

Re: Is everything ok on our Jenkins cluster?

I looked at Jenkins and saw them all as connected and in sync. Is there more to the report or was this some sort of networking burb? On Wed, Jun 17, 2020 at 2:20 PM Joan Touzet wrote: > > IBM maintains these workers for us - will have to ask Paul Davis to take > a look. > > -Jo

Re: [DISCUSSION] Emit an instance ID value in DB info API response in CouchDB 4.0

We already have the uuid generated. I'd suggest just adding a `uuid` field that exposes it. On Tue, May 26, 2020 at 1:27 PM Nick Vatamaniuc wrote: > > Hi everyone, > > I was wondering if we could expose an "instance_id" field in the top > level `/` (db_info) result. The value would be a uuid

Re: Partitions list

Currently no, and comp sci theoretically nothing that’ll be any more efficient internally than the obvious map/reduce view. On Sun, May 24, 2020 at 12:48 PM ermouth wrote: > Hi devs, > > is there a way to get the list of DB partitions, except dedicated > map/reduce? Trying to add partitioned

Re: Should we continue with FDB RFC's

Can +1 but its gonna feel really silly when I think about how the code is already merged... On Tue, May 19, 2020 at 12:28 PM Joan Touzet wrote: > > Looks like the Mango one has the required +1 already. > > There's reviews of the map index one by Adam, Paul, and Mike (Rhodes) > but neither have

Re: [DISCUSS] Streaming API in CouchDB 4.0

Seems reasonable to me. I'd agree that setting query string parameters with a bookmark should be rejected. I was also going to suggest eliding the href member. In the examples I've seen those are usually structured as something like: "links": { "previous": "/path/and/qs=foo", "next":

Re: API versioning

omit this option and just have the path option, the query parameter option > and the custom header option. > > B. > > > On 27 Apr 2020, at 22:34, Paul Davis > wrote: > > > > Overall this looks quite good to me. The only thing I'd say is that we > > should s

Re: API versioning

Overall this looks quite good to me. The only thing I'd say is that we should set our version much earlier so we can eventually rely on this for selecting an entirely independent implementation. Though that's not very pressing as once we have the concept embedded we can extend it as needed. For

Re: [DISCUSS] Streaming API in CouchDB 4.0

I'd agree that my initial reaction to cursor was that its not a great fit, but there does seem to be the existing name used in the greater REST world for this sort of pagination so I'm not concerned about using that terminology. I'm generally on board with allowing and setting some default sane

Re: Cloudbees Operations Center and Client Masters upgrade this weekend.

Howdy Gavin, I've updated everything besides the two FreeBSD nodes that Joan manages. Is there a trick to having Jenkins realize a node has upgraded its slave.jar? Took me an extra twenty minutes fumbling around before realizing that slave.jar is now actually agent.jar and that even though

Re: Getting FDB work onto master

There are a few other bits to `make check` that aren't included in `make check-fdb`. Updating `make check` should just be a matter of taking our test subset and applying them to `make check`. On Tue, Mar 31, 2020 at 11:04 AM Garren Smith wrote: > > On the fdb branch we have a make check-fdb

Re: [DISCUSS] Mango indexes on FDB

nate (3) from your list of things. > > 1. If user specifies an index, use it even if we have to wait > 2. If an index is built that can be used, use it > 3. n/a > 4. As a last resort use _all_docs > > > On Thu, 26 Mar 2020 at 16:59, Paul Davis > wrote: > > &

Re: [DISCUSS] Mango indexes on FDB

oing to allow queries to span transactions. This is already > > implemented for views and will be for mango > > > > > > > > > > Cheers, > > > > > > Will > > > > > > On Wed, 25 Mar 2020 at 19:43, Garren Smith wro

Re: [DISCUSS] Mango indexes on FDB

imeouts when somebody adds a new index. > > > > > > > > As I understand it, we're not allowing queries to span FDB transactions > > > so > > > > this latter case is not something to worry about? > > > > > > > > > We are going

Re: [DISCUSS] Mango indexes on FDB

> It was therefore felt that having an immediate "Not ready" signal for just > _some_ calls to _find, based on the type of backing index, was a bad and > confusing api. > > We also discussed _find calls where the user does not specify an index, and > concluded that we would be free to choose

Re: [DISCUSS] soft-deletion

for preferring to build soft deletion on top > of FDB (and thus have also intentionally withheld more of the cons of this > approach, or the pros of yours). > > > On Mar 18, 2020, at 11:59, Paul Davis wrote: > > > > Alex, > > > > All joking aside, soft-

Re: [DISCUSS] soft-deletion

Alex, All joking aside, soft-deletion's target use case is accidental deletions. This isn't a replacement for backup/restore which will still happen for all the usual reasons. Paul On Wed, Mar 18, 2020 at 1:42 PM Paul Davis wrote: > > On Wed, Mar 18, 2020 at 1:29 PM Alex Miller &g

Re: [DISCUSS] soft-deletion

On Wed, Mar 18, 2020 at 1:29 PM Alex Miller wrote: > > > > On Mar 18, 2020, at 05:04, jiangph wrote: > > > > Instead of automatically and immediately removing data and index in > > database after a delete operation, soft-deletion allows to restore the > > deleted data back to original state

Re: [DISCUSS] moving email lists to Discourse

Ah, fair point! On Thu, Mar 12, 2020 at 10:25 AM Jan Lehnardt wrote: > > > > > On 12. Mar 2020, at 16:21, Paul Davis wrote: > > > > I'm not against anything of that nature, but if memory serves the > > email lists are dictated by ASF policy. > > If you rem

Re: [DISCUSS] moving email lists to Discourse

I'm not against anything of that nature, but if memory serves the email lists are dictated by ASF policy. On Thu, Mar 12, 2020 at 9:32 AM Garren Smith wrote: > > Hi All, > > The CouchDB slack channel has been a real success with lots of people > asking for help and getting involved. The main

Re: CI for prototype/fdb-layer branch

On Wed, Feb 19, 2020 at 4:51 AM Ilya Khlopotov wrote: > > Sounds harder than I hoped. :-( > I was a bit out of it yesterday so dunno if my email went through properly. Though I was trying to say the crazy docker bits should not be an issue. dev/run and eunit already have the smarts to start fdb

Re: CI for prototype/fdb-layer branch

If memory serves, fdbserver is statically linked by default which should save some work. On Tue, Feb 18, 2020 at 8:13 PM Paul Davis wrote: > We probably don’t need fancy Docker here. Eunit and dev/run already setup > fdbserver automatically if the binary is found. A two stage

Re: CI for prototype/fdb-layer branch

We probably don’t need fancy Docker here. Eunit and dev/run already setup fdbserver automatically if the binary is found. A two stage build that copies fdbserver into the existing image is probably all that needs to happen. I’m limited to typing one handed for the forseeable future so I won’t

Re: [ANNOUNCE] Juan José Rodriguez elected as CouchDB committer

Welcome to the party! On Fri, Feb 7, 2020 at 1:41 PM Jay Doane wrote: > > Congrats Juanjo! Thanks for all your hard work, and welcome aboard! > > On Fri, Feb 7, 2020 at 11:29 AM Joan Touzet wrote: > > > Dear community, > > > > I am pleased to announce that the CouchDB Project Management

Re: FDB: Map index key/value limits

For A you also want to consider multiple emitted K/Vs on whether we index some or none. I'd assume none as that would match the existing equivalent of a doc throwing an exception during indexing. On Thu, Jan 16, 2020 at 8:45 AM Garren Smith wrote: > > Hi Everyone, > > We want to impose limits on

Re: [DISCUSS] Minor replicator error reporting API change

+1 On Fri, Dec 20, 2019 at 12:33 PM Nick Vatamaniuc wrote: > > Hi everyone, > > Before 3.0 goes out, I wanted to propose a minor replicator > _scheduler/* API change. > > Currently when a replication job is crashing it reports the error as a > string in the "info" field. So that that "info"

Re: Request: Committers, delete your old branches on apache/couchdb!

I noticed that there are a lot of branches pointing at commits that have been merged to master. I'll hack up a quick script today that will go through all branches and delete anything that's been merged. I'll write out the specific branch/sha combinations and report them here in case anyone really

Re: [PROPOSAL] Drop Erlang 19 support in CouchDB 3.0

2019 at 3:27 PM Joan Touzet wrote: > > Sure...do you mean just in the release notes, or some tangible change to > rebar.config.script / configure? > > -Joan > > On 2019-12-12 4:06 p.m., Paul Davis wrote: > > +1 > > > > The only thought that comes to mind is that it

Re: Script for displaying test errors and timing information

th the log stasher. > This could allow graphing if someone wants to build a neato D3 thing > that hits the couchdb-vm2 instance for stats. > > On 2019-12-12 3:51 p.m., Paul Davis wrote: > > Hey all, > > > > I was poking around at Jenkins the other day trying to get a good ide

Re: [PROPOSAL] Drop Erlang 19 support in CouchDB 3.0

ber wrote: > > On Thu, 12 Dec 2019, at 01:35, Joan Touzet wrote: > > Hello everyone, > > > > I'm working this week with Paul Davis on our new Jenkins CI > > infrastructure, which is coming along nicely. One of the changes I'm > > planning to make is that our PR tests

Script for displaying test errors and timing information

Hey all, I was poking around at Jenkins the other day trying to get a good idea of how much time we're spending in various parts of the build. It occurred to me that one good way to at least investigate our eunit test suite is to parse all of the generated surefire reports. I spent an hour or so

Re: [DISCUSS] Node types in CouchDB 4.x

Sounds reasonable assuming you made a typo here: > By default, with any extra configuration, the behavior would stay as is > today... I assume that should have been "without any extra configuration"? On Tue, Nov 19, 2019 at 11:11 AM Nick Vatamaniuc wrote: > > Hi everyone, > > I'd like to

Re: Introduction of open tracing (otter)

an be specified if we use > start_with_tags(Name, InitialTags, TraceId, ParentId). > > On 2019/09/10 21:43:02, Paul Davis wrote: > > Looks pretty awesome. I've got basically the same questions as Koco on > > performance. There are also games like the lager transforms that &g

Re: Introduction of open tracing (otter)

am > > > On Sep 10, 2019, at 5:43 PM, Paul Davis wrote: > > > > Looks pretty awesome. I've got basically the same questions as Koco on > > performance. There are also games like the lager transforms that > > conditionally enable/disable log levels at runtime. If mem

Re: Compaction daemon changes

wrote: > > I was just going to port over the `check_period` function and add support for > “from” and “to” as per-channel config parameters, so I don’t think it will > meaningfully help with the rationalization of the config systems. > > Adam > > > On Sep 6, 2019, at

Re: Compaction daemon changes

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 trivial to support? On Fri, Sep 6, 2019 at 8:25 AM Adam Kocoloski wrote: > > Hi all, > > CouchDB

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

+1 On Wed, Aug 14, 2019 at 9:07 AM Jan Lehnardt wrote: > > Agreed, and recon’s BSD 3-clause is totally fine as per > https://apache.org/legal/resolved.html#category-a > > +1 > > Best > Jan > — > > > On 14. Aug 2019, at 15:36, Robert Newson wrote: > > > > I’m for the proposal and am confident

Re: [PROPOSAL] Deprecate several mailing lists

+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 > > > — > > > > > > > On 1. Aug 2019, at 18:33, Joan Touzet

Re: [VOTE] Adopt FoundationDB

+1 On Tue, Jul 30, 2019 at 10:06 AM Nick Vatamaniuc wrote: > > +1 > > On Tue, Jul 30, 2019 at 10:25 AM Wendall Cada wrote: > > > +1 > > > > On Tue, Jul 30, 2019 at 7:08 AM Adam Kocoloski > > wrote: > > > > > +1 > > > > > > > On Jul 30, 2019, at 4:27 AM, Jan Lehnardt wrote: > > > > > > > >

Re: Fsyncgate: errors on fsync are unrecovarable

I’m browsing on my phone but I’m pretty sure we should add an `ok =` to this line so that we force a bad match: https://github.com/apache/couchdb/blob/9d098787a71d1c7f7f6adea05da15b0da3ecc7ef/src/couch/src/couch_file.erl#L223 Unless I’m missing somewhere else that we’re making that assertion.

Re: [VOTE] amend the bylaws

+1 Also for others fighting GitHub's side scrolly thing, this article made review significantly easier: https://www.viget.com/articles/dress-up-your-git-diffs-with-word-level-highlights/ On Mon, Jul 1, 2019 at 9:55 AM Naomi S wrote: > > hello, > > I have prepared a pull request that amends the

Re: Use ExUnit to write unit tests.

On Thu, May 23, 2019 at 11:04 AM Joan Touzet wrote: > > On 2019-05-23 11:15, Paul Davis wrote: > > I'm pretty happy with the ExUnit we've got going for the HTTP > > interface and would be an enthusiastic +1 on starting to use it for > > internals as well. > >

Re: Use ExUnit to write unit tests.

I'm pretty happy with the ExUnit we've got going for the HTTP interface and would be an enthusiastic +1 on starting to use it for internals as well. The only thing I'd say is that the adapter concept while interesting doesn't feel like it would be that interesting for our particular situation. I

Re: Numbers in JavaScript, Lucene, and FoundationDB

Its late so just a few quick notes here: Jiffy decodes numbers based on their encoding. I.e., any number that includes a decimal point or exponent is decoded as a double while any integer is decoded as an integer or bignum depending on size. While encoding jiffy will also encode 1.0 as "1.0" and

Re: [DISCUSS] couch_event and FDB

On Mon, Apr 29, 2019 at 1:29 PM Nick Vatamaniuc wrote: > > After discussing how replicator might be implemented with fdb > https://lists.apache.org/thread.html/9338bd50f39d7fdec68d7ab2441c055c166041bd84b403644f662735@%3Cdev.couchdb.apache.org%3E, > and thinking about a global jobs queue for

Re: [DISCUSS] Statistics maintenance in FoundationDB

I've only got two notes for color. I'm pretty sure that keeping the update_seq as a key could be fine since its an atomic op underneath and shouldn't conflict. However given that we're looking to store an Incarnation and Batch Id with every version stamp I still think it makes better sense to

Re: Prototype CouchDB Layer for FoundationDB

> > know more chime in. It seems a bit similar to how we had the > > instance_start_time at one point or how we add the suffix to db shards. > > > > Great work! > > -Nick > > > > On Wed, Mar 27, 2019 at 12:53 PM Paul Davis > > wrote: > > >

Prototype CouchDB Layer for FoundationDB

Hey everyone! I've gotten enough of a FoundationDB layer prototype implemented [1] to start sharing publicly. This is emphatically no where near useful to non-CouchDB-developers. The motivation for this work was to try and get enough of a basic prototype written so that we can all start fleshing

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

a way that > allows us to upgrade to a smarter KV encoding over time without major > surgery, which I think is a good “layer of abstraction”. I would be nervous > if we started having abstract containers of data structures pushed down into > FDB itself :) > > Adam > > >

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

, Feb 19, 2019 at 5:45 PM Joan Touzet wrote: > Would it be too much work to prototype both and check CRUD timings for > each across a small variety of documents? > > -Joan > > - Original Message ----- > > From: "Paul Davis" > > To: dev@couchdb.apache.or

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

A simple doc storage version number would likely be enough for future us to do fancier things. On Tue, Feb 19, 2019 at 4:16 PM Benjamin Anderson wrote: > > I don’t think adding a layer of abstraction is the right move just yet, > I think we should continue to find consensus on one answer to

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

> I'm very interested in knowing if anyone else is interested in going this > simple, or considers it a wasted opportunity relative to the 'exploded' path. > Very interested because this is how the Record Layer stores their protobuf messages.

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

action needs the full revision tree for a single > document it can retrieve that with a single range read for the (“_meta”, > DocID) prefix. > > Adam > > > On Feb 8, 2019, at 6:35 PM, Paul Davis wrote: > > > > Ah, that all sounds good. The only thing I'm not in

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

The _by_field indexes are a bit worrisome there. We've had users toss UUIDs and email addresses into keys which then blows the size of those indexes through the roof which causes all sorts of badness. On Fri, Feb 8, 2019 at 6:48 PM Ilya Khlopotov wrote: > > # Data model without support for per

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

g a deleted leaf. Do we fail that as a conflict? That would be the > natural thing to do here, otherwise we’re forced to check both deleted=false > and deleted=true keys > - the keys can be made to naturally sort so that the winning revision sorts > last, but I don’t believe that’s

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

On Thu, Feb 7, 2019 at 9:35 PM Adam Kocoloski wrote: > > Bob, Garren, Jan - heard you loud and clear, K.I.S.S. I do think it’s a bit > “simplistic" to exclusively choose simplicity over performance and storage > density. We’re (re)building a database here, one that has some users with > pretty

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

> I’m relatively happy with the revision history data model at this point. I forgot to make a note, but which of the various models are you referring to by "revision history data model". There's been so many without firm names that my brain is having a hard time parsing that one. On Thu, Feb 7,

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

Cheers to that Garren! Whatever we decide on for the data model I'd like to see a fairly extensive property based test suite around it. I almost said for anything above chunked based storage but even for that I'd think that I'd still want property testing around various keys and tree mutations.

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

Jiffy preserves duplicate keys if its not decoding into a map (in which case last value for duplicate keys wins). Its significantly corner case and not at all supported by nearly any other JSON library so changing that shouldn't be considered a breaking change in my opinion. On Wed, Jan 30, 2019

Re: [couchdb] uuid cluster set up

And for background, that value is used for replication checkpoints. The consequences of changing it between upgrades is that you would be resetting any replications into and out of the cluster. It wouldn't be end of the world consequences if it broke but would cause downtime/replication delay if

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

+1 On Thu, Dec 20, 2018 at 8:15 AM Eiri wrote: > > +1 > > > > On Dec 20, 2018, at 04: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

Re: [NOTICE] Mandatory relocation of Apache git repositories on git-wip-us.apache.org

+1 On Fri, Dec 7, 2018 at 10:58 AM Joan Touzet wrote: > > Requesting lazy consensus - does anyone have a problem with them > starting the process to mass-migrate all of the remaining repos to > gitbox? > > This means integrated access and easy PRs on repos like couchdb-admin, > couchdb-ets-lru,

Re: Elixir suite has landed on master!

Yay! On Thu, Nov 8, 2018 at 12:36 PM Adam Kocoloski wrote: > > Oh, very cool. Glad to see that get merged! > > Adam > > > On Nov 8, 2018, at 11:23 AM, Joan Touzet wrote: > > > > Resending since my first email didn't get through... > > > > In case you're not on notifications@, you may have missed

Re: Exact definition of a database "active size"

we are using three different size attributes in a > >> database info: file - the size of the database file on disk; external - > >> the uncompressed size of database contents and active, defined as “the > >> size of live data inside the database” or “active

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

+1 On Thu, Jul 5, 2018 at 5:18 AM Andy Wenk wrote: > > +1 > > -- > Andy Wenk > Hamburg - Germany > RockIt! > > GPG public key: > http://pgp.mit.edu/pks/lookup?op=get=0x45D3565377F93D29 > > > > > On 5. Jul 2018, at 11:21, Garren Smith wrote: > > > > +1 to this as well. We just don't have enough

Re: Proposal: removing view changes code from mrview

+1 On Tue, Apr 3, 2018 at 9:23 AM, Joan Touzet wrote: > +1. > > 1. No one has worked on a fix since its contribution prior to 2.0. > 2. The code will always be in git in an older revision if someone is > looking for it. > 3. We have #592 which describes the fundamental

Re: [ANNOUNCE] Peng Hui Jiang elected as CouchDB committer

Congrats! On Sat, Mar 3, 2018 at 2:24 PM, Andy Wenk wrote: > Welcome Peng ;-) > > -- > Andy Wenk > Hamburg - Germany > RockIt! > > GPG public key: > http://pgp.mit.edu/pks/lookup?op=get=0x45D3565377F93D29 > > > > > On 3. Mar 2018, at 19:04, Nick Vatamaniuc

Re: [AMEND OFFICIAL DOCUMENTS] Bylaws revision: HTTP API change notifications

Echoing my PR +1 here. On Mon, Feb 12, 2018 at 10:39 AM, Joan Touzet <woh...@apache.org> wrote: > Hi everyone, > > I have incorporated minor feedback from Robert Newson and Paul > Davis. > > https://github.com/apache/couchdb-www/pull/27 > > The changes reflect th

Re: [RFC] On the Testing of CouchDB

> The one thing that would be nice here if it were easy to disable certain > tests or suites that make no sense in the pouchdb-server environment, so > they can easily integrate it in their CI. The cool thing is that Elixir supports this natively in that you can add tags to test to selectively

Re: [RFC] On the Testing of CouchDB

` itself. On Fri, Dec 15, 2017 at 11:45 AM, Paul Davis <paul.joseph.da...@gmail.com> wrote: > For `make check` it should be fairly straightforward to map the > current approach to it. I could probably knock that out fairly quickly > if you want me to give it a whirl. > > On Fri, Dec

Re: [ANNOUNCE] Nick Vatamaniuc joins the PMC

Hooray and welcome, Nick! On Sat, Nov 11, 2017 at 2:45 PM Joan Touzet wrote: > Congratulations! Welcome, Nick! > > - Original Message - > From: "Alexander Shorin" > To: priv...@couchdb.apache.org > Sent: Saturday, 11 November, 2017 1:31:36 PM >

Re: [VOTE] Release Apache CouchDB 1.7.1-RC1

make check all green on OS X 10.12 +1 On Fri, Nov 10, 2017 at 12:52 PM, Adam Kocoloski wrote: > +1 > > Adam > >> On Nov 10, 2017, at 9:20 AM, Jan Lehnardt wrote: >> >> Dear community, >> >> I would like to release Apache CouchDB CouchDB 1.7.1-RC1. >> >>

Beginning merge of Pluggable Storage Engines

Hi everyone! I've been working the last few days on getting the PSE PRs rebased on master to get that feature merged in. There are two PRs [1,2] associated with this work. Given that this is a fairly decent change I'm running the bases on making sure everyone has buy in to it before just pulling

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

Yeah, +1 to +1'ing your own PR when its trivial. Minor annoyance but its a paper trail of sorts anyway. On Fri, Aug 18, 2017 at 10:55 AM, Joan Touzet wrote: > I didn't realize you could review your own PR. That gives us the "escape > hatch" that we need. > > -Joan > > -

Re: [DISCUSSION] Moving to a stricter quarterly release cycle?

I can see all of 3, 4, and 6 month release cycles. Before committing to this I'd like to see what the current process is like and how much "work" is actually involved. Theoretically if this were a "bump version number, write email, push button" sort of situation then I'd be quite happy going this

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

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 branch unless CI test runs > against that PR are clean. > > We've worked hard as a group

Re: [VOTE] Release Apache CouchDB 2.1.0-RC1

Agreed. On Wed, Aug 2, 2017 at 1:59 PM Jan Lehnardt <m...@jan.io> wrote: > Yeah, that's the idea. I'll look into the build script. This is not a > fault in CouchDB but my mac packaging > > Cheers > Jan > -- > > > On 2. Aug 2017, at 20:13, Paul Davis <

  1   2   3   4   5   6   7   8   9   10   >