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 beginnings of that here: https://forums.foundationdb.org/t/couchdb-considering-rearchitecting-as-an-fdb-layer/1088/15). We intend to grow that relationship, in particular around governance but also including the things that concern you. On attachments, I completely agree with you that we should choose one of the two options you mention. I think FoundationDB will allow robust attachment support (https://apple.github.io/foundationdb/data-modeling.html#large-values-and-blobs). That said, CouchDB is not designed as a BLOB storage system. Attachments were originally part of the couchapp manifesto. I would like to see attachment support preserved (but radically improved) but that topic is one for the wider couchdb dev team to consider. The alternative, full removal of the feature, has its advocates too. -- Robert Samuel Newson rnew...@apache.org On Fri, 1 Feb 2019, at 17:21, Eli Stevens (Gmail) wrote: > A couple other topics that I think would make sense to discuss: > > - How to manage edge-case performance or capability regressions resulting > from the switch. My former team couldn't use 2.x in production until > 2.2 due to a handful of these kinds of issues. What's going to happen when > users blocked due to things that can only be addressed on the FoundationDB > side of things? Will CouchDB have a privileged seat at the table when it > comes to requesting bugfixes or performance improvements from the > FoundationDB team? > - What's going to happen to attachments? I'd really like them to get out > of the "supported, but conventional wisdom is don't use them" limbo they're > in now (either by becoming a first-class feature, or by officially > deprecating them). > > Cheers, > Eli > > On Thu, Jan 31, 2019 at 9:40 AM Adam Kocoloski <kocol...@apache.org> wrote: > > > > > > On Jan 31, 2019, at 12:27 PM, nicholas a. evans < > > nicholas.ev...@gmail.com> wrote: > > > > > >> I called out the problems with reduce functionality in the first post > > of this thread specifically to shake out people's concerns there, so thank > > you for voicing yours. The current approach to reduce only works because we > > control the writing of the b+tree nodes, including when they're split, etc, > > so we're able to maintain intermediate values on the inner nodes as the > > data changes over time. This is not something we can do with FoundationDB > > directly (or, indeed, anything else). We're looking for a solution here. > > > > > > Yes, I don't want to dive too deep into the nitty gritty here (my > > > experience with FoundationDB is only a quick skim of the docs, > > > anyway). I was thinking of something along the lines of making a > > > pseudo-btree (just for reductions, distinct from the map emits) where > > > each btree node is a FoundationDB value. It might not be useful or > > > efficient for anything *other* than ranged reduce queries, so perhaps > > > it could be opt-in per ddoc or per view (and v4.x, where x > 0). It > > > could be updated within the same transactions as the map emits, or > > > maybe it could be updated as a cache layer separately from the map > > > emits. > > > > That’s at least the third time I’ve heard someone independently come up > > with this idea :) I think it could work, if anyone has the cycles to sit > > down and write that code. > > > > Adam > > > >
