I agree on the anti-pattern. Concurrency control seems to be more of a cluster property. I do think, however, that the optimization isn’t a “bad” thing. It just shouldn’t be a requirement for operation and never be relied upon as an assumption.
Simply put: if and only if the revs match we should assume some optimism just like we do with things like atts_since. There’s already a lot of trust between two nodes for replication and we should assume that matching revs were either unique (or random) or based on some deterministic property that isn’t likely to collide unless it was an equivalent operation. I’d encourage PouchDB to keep random revs unless they have some internal need to change it. Even then, I think it’s PouchDB’s choice to generate revs however it wants as long as it follows these semantics. Brian. > On Oct 17, 2014, at 9:20 AM, Dale Harvey <[email protected]> wrote: > > Does anyone have a compelling reason for this optimisation existing? > > I cant think of many reasons for a user to be sending the same writes to > different servers then not wanting them to conflict, I feel like its an > anti pattern and I feel like if I make seperate writes and they dont > conflict when I replicate, something is broken. Considering where there are > a lot of huge and fairly easy wins in replication, spending any time on > this almost never touched case doesnt seem worth it. > > PouchDB just uses random revs, the only people that have cared have known > the inner working of couchdb, a pouchdb user has never been confused by the > behaviour as far as I can remember. > > On 17 October 2014 13:45, Alexander Shorin <[email protected]> wrote: > >> Hi Chris, >> >> I'd already opened an issue to track this down: >> https://issues.apache.org/jira/browse/COUCHDB-2338 >> >> If anyone has some plan, it better to be there. >> >> -- >> ,,,^..^,,, >> >> >> On Fri, Oct 17, 2014 at 3:38 PM, Chris Anderson <[email protected]> >> wrote: >>> Wouldn't it be cool if we all generated interoperable revision hashes? >>> >>> I can't point any fingers because as far as I can tell, Couchbase is >>> promulgating at least 3 different revision hash generation schemes. >>> >>> I've filed an issue for us here: >>> https://github.com/couchbase/mobile/issues/3 >>> >>> Part of the problem is CouchDB's use of term_to_binary: >>> >> https://github.com/apache/couchdb-couch/blob/d28af185295d4618b489c050bcc71407e89891f1/src/couch_db.erl#L820 >>> >>> I've seen this discussed informally, but I don't know if anyone has a >>> tractable plan to get us there. >>> >>> Cheers, >>> Chris >>> >>> -- >>> Chris Anderson @jchris >>> http://www.couchbase.com >>
