937 track conflicts in db info

[bdionne]

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.

[kocolosk]

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?

[davisp]

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.

[kocolosk]

Cool. A versioned record would certainly be cheaper than a proplist on disk.

[adam]

@davisp, love ya...but I'm not the adam you're looking for.

[davisp]

@adam Oopsie, apologies for the noise. Just switched over from JIRA where we use @-notation on real names instead of user names.

[bdionne]

@davisp I'm not sure what you mean by compatibility matrices, but I suspect what happens porting this to couchdb[1] is an example of that.

[1] bdionne/couchdb@48d8eab

[davisp]

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