When I try to add design documents (beginning with "_") I get an error "Only reserved document ids may start with underscore." How can I add a design document?
According to the Definitive Guide, a design document like this one:
{
"_id" : "_design/example",
"views" : {
"foo" : {
"map" : "function(doc){ emit(doc._id, doc._rev)}"
}
}
}
can be added to the database named basic with a curl command like this:
curl -X PUT http://127.0.0.1:5984/basic/_design/example --data-binary #mydesign.json
Personally, I find it much easier to use CouchApp to add and manage design documents. This section of the Definitive Guide describes how to install and use it.
Related
What is the exact procudure to add a CommonJs module on couchdb ?
I've read tutorials like:
https://caolan.org/posts/commonjs_modules_in_couchdb.html
from official doc:
http://docs.couchdb.org/en/1.6.1/query-server/javascript.html#commonjs-modules
The CommonJS module can be added to a design document, like so:
{
"views": {
"lib": {
"security": "function user_context(userctx, secobj) { ... }"
}
},
"validate_doc_update": "function(newdoc, olddoc, userctx, secobj) {
user = require('lib/security').user(userctx, secobj);
return user.is_admin();
}"
"_id": "_design/test"
}
but where I copy or paste that code? must I save to the file and add it with curl ? On fauxton i don'see where.
Managing CouchDB design documents is usually best accomplished via a tool like couchapp. It allows you to package up a directory of files and outputs a CouchDB design document.
You can manually edit that JSON in the futon/fauxton editor, but it's a pain and there are other tools out there depending on your toolchain. An external tool like this also aids in deployment, particularly across different environments.
Here's what I'm doing:
First, I make a search and get some documents
curl -XPOST index/type/_search
{
"query" : {
"match_all": {}
},
"size": 10
}
Then, I'm updating one of the documents resulted in the search
curl -XPOST index/type/_id/_update
{
"doc" : {
"some_field" : "Some modification goes here."
}
}
And finally, I'm doing exactly the same search as above.
But the curious thing is that I get all the previous documents, except the updated one. Why is it no longer among the documents in the search?
Thank you!
Since you're not sorting your documents, they are sorted by score. Your modification might have changed the document score after which the documents are sorted by default.
And since you're only taking the first 10 documents, you have no guarantee that your new document will come back in those 10 documents.
Is it possible to only retrieve the _source document(s) when I execute a search query with the (official) nodejs-elasticsearch library? According to the documentation, there seems to be a way, sort of:
Use the /{index}/{type}/{id}/_source endpoint to get just the _source field of the document, without any additional content around it. For example:
curl -XGET 'http://localhost:9200/twitter/tweet/1/_source'
And the corresponding API call in the nodejs library is:
client.getSource([params, [callback]])
However, this method only seems to be able to retrieve documents on an ID basis. I need to issue a full search body (with filters and query_strings and whatnot), which this method doesn't support.
I'm running ES 1.4
You can use "fields" for this. See a simplified example below. Go ahead and customize your query as per your requirement:
{
"fields": [
"_source"
],
"query": {
"match_all": {}
}
}
The value of fields _index, _type, _id and _score will always be present in the response of Search API.
I'd like to have a flexible schema in Mongo, but would also like to enforce a schema for subsequent updates. Is it possible to store the validation in the document like the following?
I have tried this, but can't seem to convert the string into a Joi object.
{
"_id" : ObjectId("53d5dce1fc87899b2b3c2def"),
"name" : {
"validator" : "Joi.string().alphanum().min(3).max(30).required()",
"value" : "Bob"
},
"email" : {
"validator" : "Joi.string().email()",
"value" : "bob#gmail.com"
}
}
Most of the time, storing executable code in a database is not a good idea. What will you do when you realize a validator function which is already stored in a billion documents needs to be modified? What if someone manages to insert a document with validation code which does more malicious stuff than just validating?
I would really recommend you to determine the type of the document and the appropriate validation routine for each type in node.js.
But when you insist on having executable code for each document in the document itself, you can run that code in node.js using the vm.runInContext(object.validator, object) method. Keep in mind that this requires access to the whole document in node.js, so you can not do partial updates. Also keep in mind that, as I said, it might not be a very good idea.
In the upcoming Mongo 3.2 version they are going to add document validation (slides).
It will work in a different way and looking at your requirements it looks like it is possible to achieve what you want. It is possible to specify the type of the field, check the existence and pass through regex.
Here is a little bit about validation. You can specify validation rules for each collection, using validator option using almost all mongo query operators (except $geoNear, $near, $nearSphere, $text, and $where).
To create a new collection with a validator, use:
db.createCollection("your_coll", {
validator: { `your validation query` }
})
To add a validator to the existing collection, you can add the validator:
db.createCollection("your_coll", {
validator: { `your validation query` }
})
Validation work only on insert/update, so when you create a validator on your old collection, the previous data will not be validated (you can write application level validation for a previous data). You can also specify validationLevel and validationAction to tell what will happen if the document will not pass the validation.
If you try to insert/update the document with something that fails the validation, (and have not specified any strange validationLevel/action) then you will get an error on writeResult (sadly enough the error does not tell you what failed and you get only default validation failed):
WriteResult({
"nInserted" : 0,
"writeError" : {
"code" : 121,
"errmsg" : "Document failed validation"
}
})
I really don't know what's going on with my configuration, but I'm just not able to query anything after indexing (don't even know if I'm doing the indexing part correctly). Could someone please tell me what each of the following means and should be?
I have a CouchDB database called bestdb. Inside this database I have document types like product and customer.
Now I installed elastic search version 0.18.7 and the corresponding couchdb river. I started elastic search and couchdb. I set the network.host of elasticsearch to be an ip address: 10.0.0.129 . I followed the instructions in the tutorial :
curl -XPUT '10.0.0.129:9200/_river/{A}/_meta' -d '{
"type" : "couchdb",
"couchdb" : {
"host" : "localhost",
"port" : 5984,
"db" : "bestdb",
"filter": null
},
"index" : {
"index" : "{B}",
"type" : "{C}",
"bulk_size" : "100",
"bulk_timeout" : "10ms"
}
}'
{A}: What's this? My understanding is that this is just an internal elastic search index right? It's not being used for querying or searching right? So this could be any name right?
{B}: What's this index? How is this different from the one above? What should the value of this be in my scenario?
{C}: Is this related to the Document Type in couchdb, like product or customer ?
The online tutorial just sets everything to be the same value. How would my curl statement look like if I wanted to query all product documents or customer documents?
Thank you to whoever that clears things up a bit for me.
Regards,
Mark Huang
kimchy's documentation often leaves a little bit to the imagination. :-)
A is the river name. A river is just an ES document, stored in an index named _river, a type named whatever you want, and a doc id _meta.
B & C is the local index/_type that your bestdb couchdb _changes stream will get indexed into. These can be overridden by _index and _type fields in your couchdb documents. If none of the above is supplied, they'll default to your couchdb instance name bestdb/bestdb.