[
https://issues.apache.org/jira/browse/COUCHDB-3314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15928293#comment-15928293
]
Paul Joseph Davis commented on COUCHDB-3314:
--------------------------------------------
Couple points for clarification:
The random initial revision isn't *required* for clustered purge or permanent
deletes. Its merely to try and avoid some *possible* odd behavior if a user has
a specific pattern around "create doc, completely purge doc" in that if they
cycle quickly enough they may get into a state where things get a bit wonky
until they create a second revision. And that's not even known. This just makes
things a lot more sane by not having the same revisions floating around in a
given document's revision tree.
That said, the other reason this was optional was so that we could split it
between the 2.x/3.0 branch. One was to make it possible (either via API or
config) and then the second ticket was to swap the default on 3.0 release.
[~rnewson] I'd say that's only part of the swap and as [~janl] says a rare part
of the reasoning. Its after a doc is created in a db that deterministic
revisions are mostly important.
[~janl] Responding point by point:
1. That's my assumption but I haven't got any hard data either way.
2. Cool
3. This is unrelated. Purge will work the same regardless of how the doc is
created.
4/5. The escape hatch I came up with was the 0- hack. Your suggestion to
specify a revision with new_edits=false seems better on the face of it cause
that kind of even somehow matches the semantics better I think. Creating the
same doc in two different databases is almost like a "pre-creation replication"
type of operation if that makes sense.
> Add an option in doc creation APIs to specify a random value for an initial
> doc revision
> ----------------------------------------------------------------------------------------
>
> Key: COUCHDB-3314
> URL: https://issues.apache.org/jira/browse/COUCHDB-3314
> Project: CouchDB
> Issue Type: New Feature
> Components: Database Core, HTTP Interface
> Reporter: Mayya Sharipova
>
> Currently the initial revision of a document is deterministic. For instance,
> anyone that has created an empty document probably recognizes the revision
> starting with "1-967a00dff...". In order to account for situations when a
> document is continually purged and recreated we're going to add randomness to
> this initial revision by specifying a 0-$rev in the request coordinator. We
> will then include this in the revision generation but drop the 0-$rev entry
> from the revision's path.
> Thus, the new API will look like this:
> acurl -X PUT
> https://http://adm:[email protected]:5984/test-db/newdoc1?rev=0-adfdafa123 -d
> '{}'
> And similarly for _bulk_docs
> For a user who wants to create a doc, then purge it, and then re-create, it
> is recommended to recreate it with another random revision.
> It is important to note that the 0-$rev only affects document creation. Once
> a document exists, updates to the document will continue to update their hash
> in the same deterministic fashion. Ie, once a document exists, identical
> updates will result in identical revisions.
> _________________
> The following changes need to be made in the code:
> 1. API changes to allow to specify random rev in doc PUT requests, _bulk_docs
> 2. Internals:
> 2.1 Use a new revision here:
> https://github.com/apache/couchdb-couch/blob/master/src/couch_db.erl#L886
> 2.2 Don't include provided 0-$rev entry to the revision's path (find wherever
> new_revid is called from; could be 2-3 places)
> 2.3 Reject a 0-$rev during replication
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
