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