GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
Already on GitHub? Sign in to your account
This is code we had before, ported to sync with the latest on master. We're now storing a 4-tuple in the by_id btree, it's been suggested by @davisp that we move to proplists/records.
Compute and expose document conflict count in db_info api
I agree that these tuples get unwieldy, but I'd rather not add too many bytes to the on-disk representation of the reductions. I wonder if it's possible to add some assemble/extract logic to the reductions similar to what we have for the KVs themselves?
Also, the suggestion is for proplists on disk and records in memory. Writing records to disk is nearly as bad as writing bare tuples.
@adam, there might be some sort of logic there, but the underlying issue that concerns me is when we get into trying to figure out compatibility/upgrade matrices and things start getting out of control. I see your point on extra bytes in reductions though. I was thinking about some sort of helper module that would allow for a translation. Perhaps we can have a thing that makes it easier for versioning these things. I'll try and keep that in the back of my mind for a couple hours.
Cool. A versioned record would certainly be cheaper than a proplist on disk.
@davisp, love ya...but I'm not the adam you're looking for.
@adam Oopsie, apologies for the noise. Just switched over from JIRA where we use @-notation on real names instead of user names.
@davisp I'm not sure what you mean by compatibility matrices, but I suspect what happens porting this to couchdb is an example of that.
@bdionne More or less. I'm just saying that every time we add something like this, its a new entry on a compatibility axis that we have to check for. And then between BC and LC we have to do even more checking. It makes me sad.