You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@couchdb.apache.org by GitBox <gi...@apache.org> on 2020/02/25 22:34:47 UTC

[GitHub] [couchdb] davisp commented on issue #2585: Mango Indexes on FoundationDB

davisp commented on issue #2585: Mango Indexes on FoundationDB
URL: https://github.com/apache/couchdb/pull/2585#issuecomment-591107069
 
 
   Overall, this looks to be a really good first step getting mango updated for fdb. I've only had a few hours to spend reviewing this today and it'll take me a day or two to let it all soak in but there's a few things I'd like jot down while they're paged in.
   
   My first major impression is that there's an awkward cross over between couch_views and the new mango fdb modules. AFAICT, this is mostly due to the way that mango jobs stop indexing once they reach the version stamp where they were created along with being able to just update a single document. It would seem to me that if we just added these two bits as optional features of couch_views it would slim down this entire PR considerably. It might also be worth getting the basic async-index-update mango working before jumping to having the single transaction updates. It feels as there's some criss cross between the changes for a new fdb combined with changes for the incremental updates that aren't quite gelled together.
   
   The changes to fabric2_fdb need to be redone. There shouldn't be a single mention of mango in that module. There are a number of features that will want to know about db changes that should all share a single interface.
   
   For the PR itself, this should definitely be split up into smaller chunks of logic that are described individually. The last one or two might be a fairly large commit but there's a lot of churn that could be processed more efficiently stepping through individual commits. If you need help on how to break down a large commit I'd happy to pair with you to show you the basic git commands for handling that.
   
   I really like your build status concept. I'd like to extend that for views as well to show initial build vs incremental update that would be useful for operators. Moving that status under a prefix would also give us the necessary structure for efficient view cleanups as well which I'm looking at working on next.

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services