Couchbase documentation is open source, but until recently, there were a number of problems. If you were looking to make a substantial change or maybe just fix a quick typo, you were faced with one or more of these questions:

It was not always clear how to go from a documentation URL to a specific file in the Github repository.

Now, that’s changed. If you visit a page in the documentation, you will notice an "Edit on GitHub" link on each page. Click this link and you’ll be taken to GitHub to edit the file directly (your first time, you will be prompted to create a fork).

First, visit the Using Graceful Failover page in the documentation.

Next, click the "Edit on GitHub" link.

At this point, you’re on GitHub. Assuming you’ve used Git/GitHub before, the rest of this process should be familiar.

If you’ve not already created a fork, you will be prompted to do so.

After that, you will see an edit screen where you can make your change.

Once you’ve made a change, click the "Propose file change". You’ll see a diff, and you’ll be able to create a pull request.

That’s a crash course on contributing to the documentation. There’s a full guide on how to contribute to Couchbase Server docs.

Note that while that guide is written in Markdown, Couchbase Server documentation is written in the Darwin Information Typing Architecture (DITA) markup language.

For simple typo corrections, you may not need to know much about DITA, but for deeper edits, you will need to familiarize yourself with the syntax and/or an editing tool like Oxygen.

Thank you to those in the community who have already contributed! This new system has only been going for a few months, but we’ve already gotten some great contributions. So I tip my hat to:

It astounds me that we had such great contributions from so many people so quickly! Thank you, everyone, for helping to make the documentation better.

To make contribution easier, the build process had to be improved. Previously, it involved a bunch of manual steps: pull source, build locally, zip up the results, FTP them to a server, run one or more slow build server tasks manually. Now you’ll see that the build step happens much more quickly in the pull request, and previews are generated quickly.

The reviewing of content was also improved. Previously, previews were only possible on a single location. There was no simultaneous reviewing possible. This, combined with the slow, manual builds, was frustrating, and made it difficult to review all changes, let alone external ones.

Finally, backporting to other versions of Couchbase Server documentation was also a problem. The documentation is stored in separate branches for each version, so if an issue is raised and fixed in 4.6, it may also apply to 4.5, and so on. That’s a very manual process, but a @cb-docs-robot was created to automate the backporting (which you’ll see in many of the above examples).

Another thing we’ve added is the ability to give us feedback on the documentation right from your browser.

Simply find the "Feedback On This Page" button at the bottom right of your browser, click it, and write feedback.

These documentation improvements help us both internally and externally. We hope that it will make your experience with the documentation less frustrating and more enjoyable. We welcome your feedback! Please check out the Couchbase docs on GitHub.

In order to help you write efficient queries, the tooling in Couchbase Server 5.0 has been enhanced to give you a Visual Query Plan when writing N1QL queries. If you’ve ever used the Execution Plan feature in SQL Server Management Studio, this should feel familiar to you.

As a quick example, I’ll write a UNION query against Couchbase’s travel-sample bucket (optional sample data that ships with Couchbase Server). First, I’ll click "Query" to bring up the Couchbase Query Workbench. Then, I’ll enter a query into the Query Editor.

This is a relatively complex query that involves the following steps (and more):

In Couchbase Server 4.x, you could use the EXPLAIN N1QL command to get an idea of the query plan. Now, in Couchbase Server 5.0 beta, you can view the plan visually.

This tooling shows you, at a glance, the costliest parts of the query, which can help you to identify improvements.

It’s important to have tooling to monitor your queries in action. Couchbase Server 5.0 beta has tooling to monitor active, completed, and prepared queries. In addition, you have the ability to cancel queries that are in progress.

Start by clicking "Query" on the Web Console menu, and then click "Query Monitor". You’ll see the "Active", "Completed", and "Prepared" options at the top of the page.

Let’s look at the "Completed" queries page. The query text and other information about the query is displayed in a table.

Next, you can sort the table to see which query took the longest to run (duration), return the most results (result count), and so on. Finally, if you click "edit", you’ll be taken to the Query Workbench with the text of that query.

If you’ve been following along, you’ve probably already noticed the new Couchbase Web Console. The UI has been given an overhaul in Couchbase Server 5.0. The goal is to improve navigation and optimize the UI.

This new design maximizes usability of existing features from Server 4.x, while leaving room to expand the feature set of 5.0 and beyond.

New command line tooling includes cbimport and cbexport for moving data around.

cbimport supports importing both CSV and JSON data. The documentation on cbimport should tell you all you want to know, but I want to highlight a couple things:

For more about cbimport in action, check out Using cbimport to import Wikibase data to JSON documents.

cbexport exports data from Couchbase to file(s). Currently, only the JSON format is supported. Again, the documentation on cbexport will tell you what you want to know. A couple things to point out:

Here’s an example of cbexport in action (I’m using Powershell on Windows, but it will be very similar on Mac/Linux):

Notice that the key was included in an "_id" field.

Tooling for Couchbase Server 5.0 beta is designed to make your life easier. These tools will help you whether you’re writing queries, integrating with data, monitoring, or performing administrative tasks.

We’re always looking for feedback. Inside of the Web Console, there is a feedback icon at the bottom right of the screen. You can click that to send us feedback about the tooling directly. Or, feel free to leave a comment below, or reach out to me on Twitter @mgroves.

As I mentioned in the previous posts, the days of buckets with passwords are gone. The future belongs to users—​users that have specific permission(s) to specific bucket(s).

Let’s start by creating a bucket. In the Couchbase UI, login as the Administrator that you created when you installed Couchbase. Go to "Buckets" and click "ADD BUCKET" (top right). You will see the "Add Data Bucket" dialog. Notice that there is no longer a "password" field (not even in "Advanced bucket settings").

Give the bucket a name and some amount of memory, and click "Add Bucket". Now you have a bucket. But, other than an Administrator in the UI, no one can access this bucket yet.

In order to get access to this bucket, you must create a user. In Couchbase 5.0, "users" are an entirely new feature, bringing richer authentication and authorization features to Couchbase Server.

While still logged in as an administrator, go to "Security" to see a list of users. Click "ADD USER" (top right).

Create a user with whatever name and password you’d like. You can choose which roles the user has, and for which buckets (when applicable). Let’s give this user Data Writer and Data Reader roles, for the bucket that was just created (e.g. "mybucket"), but NOT any Query roles.

Once the user is added, you can hover over the roles to get a description of what the role means.

Now that we have a bucket and a user, let’s see how to use them with the .NET SDK.

Start by creating a Cluster object.

You have a cluster, but your program has not been authenticated yet. Use a PasswordAuthenticator object to specify the credentials. Then, use that object with the cluster’s Authenticate method. In this example below, I’m using incorrect credentials.

Now, if I try to perform an operation like OpenBucket on the cluster, an exception is thrown.

Now, let’s try it again using the correct credentials. Authentication will work. But let’s talk about authorization next.

Remember that I only gave this user Data Writer and Data Reader roles (for mybucket). So, if I authenticate and insert a document now, it works.

But if I tried to, for instance, execute a N1QL (SQL for JSON) query, then it would fail. This is because that user is not authorized to execute queries.

I’m just doing a simple COUNT(1) aggregation query. Since that user is not authorized, here’s what’s displayed:

If you are worried about the effect this will have on upgrading from Couchbase Server 4.x to Couchbase Server 5.0, then here’s a tip. If you create a user with the same name as the bucket (e.g. a bucket called "foo" and a user named "foo"), then the older Couchbase .NET APIs that still expect a bucket password will work as before. Just give that user a "Cluster Admin" role for now. This is a good temporary fix until you can re-engineer your system to use a regimented approach to role.

Couchbase Server 5.0 is out now in beta! These role-based authentication (RBAC) features make Couchbase a leader in document database security, and I’m personally very pleased that Couchbase is going in this direction. Security is important, but too often overlooked by developers.

If you have any questions, please ask away in the Couchbase Forums, leave a comment below, or ping me on Twitter @mgroves.