[
https://issues.apache.org/jira/browse/COUCHDB-3314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15930326#comment-15930326
]
Paul Joseph Davis commented on COUCHDB-3314:
--------------------------------------------
Couple clarifications and summary and opinion:
1. We only do the random revision for the initial revision which does *not*
include when a document is deleted and being recreated (as that causes wide
revision trees which has its own issues).
2. Random initial revisions are not a hard requirement for clustered purge, its
purely to avoid some confusing behavior in a specific scenario of create/purge
cycling with the same doc content.
3. I think we're all in agreement that letting people specify their own
revisions is still useful and theoretically already Just Works if they use
new_edits=false.
Opinion:
I'd still like to add this pre-3.0 with a config switch that we either remove
or swap the default on when 3.0 goes out. Given that at least initially we'll
want to be playing with this a lot before a 3.0 (and there's loads of other
things we have planned for 3.0 that are backwards incompatible) this still
seems best to me. Though we could also just work on specifying the revision
pre-3.0 (ie, make sure it works) and then make this change when we get all the
things ready for 3.0. Oooh, also it occurs to me that we should look at making
specifying the revision without requiring new_edits=false which only works if
the document doesn't exist. This way we can do all of this without conditioning
users to specify new_edits=false in some situations which could end up causing
conflicts.
> 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)
