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?
Related
I am looking for a workaround for primary key feature in couchdb. I am saving doc in json format to couchdb externally. Is there any simple way to check if value of a particular field exists?
If you try to save a document that already exists, it will be rejected unless the revision is set to match the existing revision.
Alternately, you can just try to fetch the document, either with GET or HEAD, to check if it exists. See the relevant documentation.
You could perform a mango query previous to the document creation but it will not warranty that another process create a document between the check and the creation.
This post discusses about the same issue:
How to check for duplication before creating a new document in CouchDB/Cloudant?
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.
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 changed one index in schema.xml and now want's to refresh all existing documents ..
How to do that ? i don't want to upload all documents again ...
any suggestion ?
if you changed the schema you HAVE TO reindex. After restarting Solr of course.
Updated:
If by 'adding one extra index' you mean adding one core, that core is empty so you have to add anything you need there.
If you change the way a field is analyzed, or add a field etc, you have to reindex again, your docs are not changed to reflect the change you made until you reindex
How are you indexing the data? If you are getting the data from a database you can use a data-import handler and use a delta-import query. The delta-import will only update newly added fields. Check out this link for full documentation:
http://wiki.apache.org/solr/DataImportHandler
I've come to really love the couchdb style of organizing and updating data, but there are a few situations where I really need to be able to create an entry and determine if an equivalent entry is already in existence before returning to the user. The only situation that this is absolutely necessary for my application is user registration. I'm fine with having all user registration writes go to a particular, designated couchdb instance known as the "registration-instance".
I want to hash the user_id into some _id to use. Then execute a put with this _id, but fail if the _id is already inserted. I need to return to the user that the user name is already reserved, and I cannot detect the conflict later and resolve it at that point, because the user would be under the impression that they had reserved the user name.
I don't see why couchdb couldn't provide some way to do this, under the assumption that you designate that inserts for a particular "type" of document always are routed to a particular instance.
If you send a single CouchDB server a PUT request for a new user document you should get the behavior you want already.
If the document does not exist then it will create the new document.
If the document does exist then it is guaranteed to return a 409 conflict error. This is due to the fact that you did not supply a _rev property because you aren't trying to update the pre-existing document.
Only when the _id and _rev properties match will CouchDB update the existing document.
You might also want to read up on document update handlers:
http://wiki.apache.org/couchdb/Document_Update_Handlers
You might use an update handler to hash the user_id and dynamically assign the appropriate _id. You can also customize what kind of error response couch sends with an update handler.
Good luck!