Absolutely!
1) I have a proposal for how conflicts are handled that I'm typing up
that's straight forward and will alleviate the need for endpoints to
compute the same revision id; it will also enable third party replication
without either side needing to do anything the same way (at the expense of
CPU time during replication when they can't do things the same way).
but 2) I'm happy to provide what I've got so far! :)
Here's a copy/paste of the documents as I've been using to test so far:
[
{"_id":"empty1","_rev":"1-967a00dff5e02add41819138abb3284d"}
{"_id":"empty2","_rev":"2-7051cbe5c8faecd085a3fa619e6e6337"},
{"_id":"foobar1","_rev":"1-4c6114c65e295552ab1019e2b046b10e","foo":"bar"},
{"_id":"foobar2","_rev":"2-0e871ef78849b0c206091f1a7af6ec41","foo":"bar"},
{"_id":"one1","_rev":"1-bab35b848b1d09f61ebb92473ad6449b","one":1},
{"_id":"one2","_rev":"2-27d66b6bb53423560f2ad1e3e870665f","one":1},
{"_id":"piSmall","_rev":"1-6fcc4c4758e81af8ffb5a7df5de39533","pi":3.1415},
{"_id":"piSmall2","_rev":"2-8ee24fd4794c01d28d0f19b33b20330e","pi":3.1415},
{"_id":"pi","_rev":"1-747554e1e394661be9216cd91b7ccc73","pi":3.14159},
{"_id":"pi2","_rev":"2-3ee614fb985a37d4ae23d73147f17904","pi":3.14159},
{"_id":"complex1","_rev":"1-329f8ae16f88bd62a8bf3de302febb2e",
"foo":"bar","baz":null,"pi":3.14159,"quux":1234,
"boolean":true,"otherboolean":false,
"list1":[1,2,3],"list2":[1,2,300],
"obj":{"a":"b"}
},
{"_id":"complex2","_rev":"2-a31473a5dd9119facc5d23564bfc210d",
"foo":"bar","baz":null,"pi":3.14159,"quux":1234,
"boolean":true,"otherboolean":false,
"list1":[1,2,3],"list2":[1,2,300],
"obj":{"a":"b"}
}
]
Documents that are missing, dedicated null, shortListSmall, shortListLarge,
and obj docs.
There's no reference at all to a long list (i.e. >= 65536) of small
integers. I only learned about the list of small integers case being
different recently.
One thing to note is that I used the _all_docs?include_docs=true URL to
dump these out of my local 1.6.1 couch and the _all_docs dump provided the
term_to_binary encoded version of the floats, while the front end web GUI
is giving me what you see above. (I've changed the docs above to use the
float values as I originally saved them and updated the MD5s to be what
they should be under the new code. Any couch install running OTP 17.0+
should already be producing the same above checksums.)
I'm assuming that the _all_docs thing has something to do with javascript
interpreting/correcting the value of the floats as pulled from the on-disk
representation while _all_docs is just sending out the on-disk
representation from erlang...
During replication I think this would technically break the pure JSON
definition of the float as "a sequence of digits" as it changes the
original sequence of digits provided in the uploaded document. Case in
point, via _all_docs, I received 3.1415000000000002 instead of the original
3.1415 I uploaded. Not the same issue as this, but something worth noting.
I'd be happy to do a PR for the above tests if someone gave me a template
to work from for the first empty doc (it should just be copy/paste from
there).
