After purging a set of documents in a Couch database, some view results contain documents which are actually not there in the database. When accessing such documents following error message is returned
{"error":"not_found","reason":"missing"}
Also the view results contain duplicate entries for some of such "missing" documents.
Some of these docs contain conflicted revisions as well.
Following is a simple view which lists such documents. According to the view, there should not be duplicate results.
function(doc) {
if (doc.documentType == 'theDocType') {
emit(theDocType, doc);
}
}
I created a new document with an id of a "missing" document, and tried purging it again (giving the new rev and all the conflicting revs). But after purging, the view results remained same as earlier.
Any idea what has caused this and how to resolve this problem ?
I just recently had this issue too and found your question.
I fixed it by deleting the view records, stored here on Windows
"...\couchdb.2.1.1\data\.dbname_design\mrview\*.view"
here on Linux
<couch data directory>/.dbname_design\mrview*.view (usually /var/lib/couchdb or /usr/local/var/lib/couchdb)
Each .view is named with an md5, delete them all, then restart the service. Then request the view again and it will rebuild this index, it might take 2 or 3 attempts before it builds it properly depending on the size of the database.
Hopefully someone can add what the linux path is.
Related
It is my understanding that couchDb stores its view index in:
<dbName>/.<designDoc>/mrview/<hashOfDesignDoc>
After querying the view, this index is created. When I delete the index file, I am still able to access the view through futon, even after clearing my cache. I do not see the view index in _active_tasks and the mrview folder remains empty.
What is going on? I would expect couchDb to reindex the view.
how to remove the deleted documents in couchdb
when temporary View is running on couchdb futon. I am getting deleted documents also.
if(!doc._deleted) and if(!_deleted_conflicts)
The above condition is used in Temporary view. But the problem is repated.
Please anyone can help me out to solve this.
Add one condition in your view like,
function(doc){
if(!doc._deleted){
emit(null,doc);
}
}
then you can avoid the deleted documents in view result.
I have a large set of documents in a CouchDB database that were just accidentally bulk deleted using _deleted:true. I also have a backup for this set of data that includes their last known good revision and metadata. I need to maintain the same _id, so simple restore with a new _id is not an option.
Compaction has not been run and I can access any of these documents via the &rev= url parameter as well as their attachments (which are needed).
What I need to do is "restore" these documents to the revision I have on file. Surprisingly, I have come up empty with any queries on how to achieve this. Tips or hacks appreciated.
If you just PUT the whole document, including the attachment stub, back into the DB, with the deleted rev, but less the _deleted:true parameter, then all will be well.
I have a view similar to this (a contrived example):
function(doc) {
if (doc.attrib) {
emit([doc.attrib],doc._id)
}
}
Everything works as expected until the data is deleted. I get this crazy scenario where there is no data in the actual database (confirmed via _all_docs and _changes run on curl as well as all_documents on Futon). However the view still yields data (again on both curl and Futon).
The delete comprises Bulk delete and purge operations via ektorp. Running _changes after each confirms these work as expected. re-creating the view makes it reflect the true state of the documents in the DB.
Have I missed something obvious here or are views in CouchDB only incremental?
Did you really _purge the data? That should invalidate the view and cause a full rebuild. I'll note that _purge is not recommended for normal use. It exists only for accidents like putting your plaintext password in a document.
You may have exposed a bug in _purge, though, so if you can reliably induce this with _purge but not if you just delete, I encourage you to file a ticket on our JIRA (https://issues.apache.org/jira/browse/COUCHDB).
I'll note also that the fix will be to blow away the index if you purge, there is no incremental approach possible (you are literally removing the information that an incremental approach requires).
I have a CouchDB database in production. One of the documents has been edited (in Futon by an other developer).
And it's lost it's ID (don't ask me how he did it).
So now the document's id is an empty string, which makes it impossible to edit or delete via Futon.
Is there a way I could hack into CouchDB to delete that document anyway ?
I couldn't delete the document. But the database itself could be deleted.
And I couldn't reproduce the bug in locale. The other developer says he just removed the _id param and saved. I don't know what happened in CouchDB when he did it. But when I do so, it only recreates a new document (as we'd expect it to do).
So I've been using couch_docs to retrieve the datas locally.
As the id is empty, couch_docs doesn't imports it. So you don't even need to delete it manually.
Then I reimport all the records in an other database. I change the references to the database name in my config and everything works fine.
Destroying the database is not a problem even though there's an empty id.
Technically, a document ID is immutable so actually changing the _id field is not directly possible. Perhaps another document was created as a copy of the first?
A bug in CouchDB 1.1.0 allowed update functions to create empty string IDs.
A similar question asks about this and I gave a walkthrough of deleting empty ids there.
I haven't tried it but LoveSeat is supposed to be able to open and edit couchedb files...
This can be caused (and fixed!) by some error checking CouchDB was missing for _update handlers, as explained in How do you delete a couchdb document with an empty "" document id?