Hi, Thanks for the links, that's the detail we need.
While we can't exclude the possibility of it, FoundationDB has an extraordinary amount of testing. It's far more likely that there will be bugs in the layer of code that we write to talk to it, which of course we can also then fix and release on our own cadence. We are working to understand what upgrades to FoundationDB mean for CouchDB users. One concern we've already seen is a brief downtime period is needed to upgrade between major versions as the network messages fdb currently sends have no versioning. Happily, this is being actively worked on and I would be surprised if that work hasn't landed in an official fdb release well in advance of the first couchdb-on-fdb release. -- Robert Samuel Newson rnew...@apache.org On Fri, 1 Feb 2019, at 18:51, Eli Stevens (Gmail) wrote: > To the best of my recollection, it was these issues: > > https://github.com/apache/couchdb/issues/745 (leading to > https://github.com/apache/couchdb/pull/1200 and then > https://github.com/apache/couchdb/pull/1253) > https://github.com/apache/couchdb/issues/1093 (also points back at 745?) > > I could have sworn there were two separate issues, but maybe it all boiled > down to the same thing in the end (I left the company in June of last year, > so I can no longer go back and check my notes). I feel fairly certain that > I remember 2.1 not working for us, and waiting for 2.1.1 (or 2.1.2?) to > land expecting a resolution, but there still being a blocking issue that > took until 2.2 to resolve. We contracted out the investigation and fixes, > with Joan as our primary point of contact. She might recall more. > > Of course, at least some (all?) of our problems were due to large-ish > attachments. :/ > > IIRC, the prerelease 2.2 nightly we had installed on some of our testing > machines was behaving well, but I was gone before 2.2 final landed. I don't > know what happened after I left. That resulted in a 4-year period where we > couldn't upgrade DB versions in production. We literally had a customer > independently find "someone in charge at CouchDB" and contact Jan because > the customer thought that we were lying to them about there not being any > DB updates we could use (this specifically was in the gap between 2.0 > landing and the availability of the Ubuntu packaging work we sponsored). > > I worry that having two separate projects with their own, independent > release cadence is going to make this kind of thing worse ("The fix we need > is in FDB 7.0, but that's still in alpha, and there are breaking changes to > some random bit of API, so once that firms up CDB will have to get updated > to match" etc.). Of course, I'm somewhat playing devil's advocate here, as > I no longer directly have skin in the game (but I like this project, and > think that logistic issues like 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 <rnew...@apache.org> wrote: > > > 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 > > > > > > > > > >
