[
https://issues.apache.org/jira/browse/COUCHDB-1163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Joseph Davis updated COUCHDB-1163:
---------------------------------------
Attachment: cleaned-up.txt
Another reference file.
This is the same tree that is in the other reference file I posted, but after
stemming with the new stemming code.
As you can see, the way that the rev tree ends up, the old rev that appeared to
be newest (that starts with the byte 223) is actually not the tip of that
revision history path thing, the leaf is the one after it is deleted. So the
data is still there, but the tree had gotten wonky so that the cleaned up
version makes it appear deleted.
So, the doc becoming deleted after cleanup does make sense. But this makes it a
bit more difficult to figure out how to find and clean other docs.
> Document returned by id, but cannot be found by rev
> ---------------------------------------------------
>
> Key: COUCHDB-1163
> URL: https://issues.apache.org/jira/browse/COUCHDB-1163
> Project: CouchDB
> Issue Type: Bug
> Components: Database Core
> Affects Versions: 1.0.1, 1.0.2
> Reporter: James Howe
> Priority: Blocker
> Fix For: 1.0.3, 1.1
>
> Attachments: COUCHDB-1163-1.1.x.patch, COUCHDB-1163.patch, Couch
> logging for jira issue, cleaned-up.txt, formatted_rev_tree.txt
>
>
> Somehow, our cluster has developed the following problem on a handful of
> documents. Will post reproduction steps if we find them. All properties have
> been redacted. All the documents this affects also have attachments, if that
> is significant. Once a document is in this situation, it causes conflict
> detection, replication and include_docs to behave incorrectly or outright
> fail.
> GET /database/4cdee83a118ea1cf3050b1d006144d46 returns
> {
> "_id": "4cdee83a118ea1cf3050b1d006144d46",
> "_rev": "10-df4bf65a6104ea240f100c30d3cb245d",
> "foo": "bar"
> }
> GET /database/4cdee83a118ea1cf3050b1d006144d46?open_revs=all returns
> [
> {
> "ok": {
> "_id": "4cdee83a118ea1cf3050b1d006144d46",
> "_rev": "10-df4bf65a6104ea240f100c30d3cb245d",
> "foo": "bar"
> }
> },
> {
> "ok": {
> "_id": "4cdee83a118ea1cf3050b1d006144d46",
> "_rev": "8-eea5e36daee12acd79a127abf36f7720",
> _deleted: true
> }
> },
> {
> "ok": {
> "_id": "4cdee83a118ea1cf3050b1d006144d46",
> "_rev": "9-2cead1e4c813a4f0d10a9bc4aa28bfda",
> _deleted: true
> }
> },
> {
> "ok": {
> "_id": "4cdee83a118ea1cf3050b1d006144d46",
> "_rev": "7-c3b44f004660caa496804409089b53d9",
> _deleted: true
> }
> },
> {
> "ok": {
> "_id": "4cdee83a118ea1cf3050b1d006144d46",
> "_rev": "6-52e978041bb324d19e01a2ac5a243702",
> _deleted: true
> }
> },
> {
> "ok": {
> "_id": "4cdee83a118ea1cf3050b1d006144d46",
> "_rev": "5-761bf28c6989f0fde41bdd5732c33159",
> _deleted: true
> }
> },
> {
> "ok": {
> "_id": "4cdee83a118ea1cf3050b1d006144d46",
> "_rev": "4-abb005cf4b2d2dd12880a33af1e7066e",
> _deleted: true
> }
> },
> {
> "ok": {
> "_id": "4cdee83a118ea1cf3050b1d006144d46",
> "_rev": "3-233e4624e620ec1c8b66f21a051832f8",
> _deleted: true
> }
> },
> {
> "ok": {
> "_id": "4cdee83a118ea1cf3050b1d006144d46",
> "_rev": "10-55f0cdf9dd95ed230b733a2c826c842c",
> _deleted: true
> }
> },
> {
> "ok": {
> "_id": "4cdee83a118ea1cf3050b1d006144d46",
> "_rev": "11-264c9d6c249ba2fc9b13df35cb447fd7",
> _deleted: true
> }
> },
> {
> "ok": {
> "_id": "4cdee83a118ea1cf3050b1d006144d46",
> "_rev": "9-2cead1e4c813a4f0d10a9bc4aa28bfda",
> _deleted: true
> }
> },
> {
> "ok": {
> "_id": "4cdee83a118ea1cf3050b1d006144d46",
> "_rev": "2-9f2df19059d9a460a12740a63a4d95e9",
> _deleted: true
> }
> }
> ]
> GET
> /database/4cdee83a118ea1cf3050b1d006144d46?rev=10-df4bf65a6104ea240f100c30d3cb245d
> returns
> {
> "error": "not_found",
> "reason": "missing"
> }
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
