Create views from CLI or N1QL?

Couchbase Server
1

We are using 4.1 version of Couchbase server. We are thinking of creating views per entity type within our product. For example, a view for “users”, a view for “accounts” etc… The documentation explains how to do that through Java SDK http://developer.couchbase.com/documentation/server/4.1/sdks/java-2.2/managing-views.html

However, in the context of what we are doing, we would like to create these views one time, up front, during product installation and have the view definition published. To do that, we plan to use the CLI or even the N1QL tool to create the views. However, we haven’t found any documentation which explains how to create these views through the CLI or N1QL cbq. Is this possible? If it isn’t then are there any other recommendations or common practices users follow for view creation?

2

The N1QL command line tool is not intended to create design documents. If you use view-backed n1ql indexes one will be created for you if you specify CREATE INDEX … USING VIEWS basically.

In general we recommend using the SDKs to create views, although there are other ways to do it. On the CLI you can use cbdocloader which accepts a .zip file and if you do the right directory structure will populate the design documents as well (see http://developer.couchbase.com/documentation/server/4.1/cli/cbdocloader-tool.html). This also how we internally populate the sample buckets I think.

The most flexible option is the one that the SDKs are using too in the background - use the REST API for the task: http://docs.couchbase.com/admin/admin/REST/rest-ddocs-create.html

Does that help?

3

Thanks @daschl, that does help. I’m going to try out the REST API approach which fits well for us. I have been reading the docs and so far haven’t found a JSON structure/schema of the design document which can be used to create views through this REST API.

The document here Couchbase SDKs shows an example which states:

-d @byfield.ddoc
Specifies that the data payload should be loaded from the file byfield.ddoc.

But I haven’t found a sample content of such files. I do see a section which shows the response of a design doc creation:

{
   "views" : {
      "byloc" : {
         "map" : "function (doc, meta) {\n  if (meta.type == \"json\") 
         	{\n    emit(doc.city, doc.sales);\n  } else 
         	{\n    emit([\"blob\"]);\n  }\n}"
      }
   }
}

So I can reverse engineer it to come up with a sample document file to add. But is there an example or document which shows what the design document that’s passed to the REST API (or even the .zip upload) should look like?

4

If you unzip the sample databases, you’ll find the design documents there in a file in a directory. The format is basically what you posted above.

Also, it’d be helpful to us if you click on the “feedback” link in the lower right to let us know where you’d like to get more info from the documentation. That creates an item for our docs team to follow up on.

5

Thanks for the help @ingenthr. Found a sample in the beer sample example. Going to try similar ones today.

As for the feedback on the documentation, will start providing them, didn’t realise the feedback provided there would be looked into.

6

Slightly OT

Just did that on one of the docs. A minor feedback on the feedback process :wink: - when I provided the feedback in the window that popped up, it asked for name and email (both of which appeared optional). I provided my email but wasn’t aware (the feedback form didn’t state it either) that the email gets publicly displayed to everyone in the JIRA that gets created. Now that I see it publicly displayed, I wanted to request to remove it from the description of that JIRA but I don’t have a JIRA login and can’t create one myself.