For the purposes of this tutorial, I’m going to use a very simple XML example. If your XML is more complex (multiple attributes, for instance), then your approach will also have to be more complex. (Json.NET can handle all XML to Json conversions, but it follows a specific set of conversion rules). Here’s a sample piece of data:

Notice that I’ve got this XML as a hardcoded string in C#. In a real-life situation, you would likely be pulling XML from a database, a REST API, XML files, etc.

Once you have the raw XML, you can create an XmlDocument object (XmlDocument lives in the System.Xml namespace).

Once you have an XmlDocument object, you can use Json.NET to convert that object into a Json representation.

In this example, I’m asking Json.NET to serialize an XML node:

Finally, let’s put the Json into Couchbase. The easiest way to do this would be to again call on JsonConvert to deserialize the Json into a C# object. That object would then be used with Couchbase’s bucket.Insert(…​) method.

With this method, the Json would be stored in Couchbase like so:

That might be fine, but often times you’re going to want more control of the format. With Json.NET, we can serialize to a given class, instead of just object. Let’s create an Invoice class like so:

Notice that there is some type information now. The Timestamp is a DateTime and the AcctNumber is an int. The conversion will still work, but the result will be different, according to Json.NET’s conversion rules. (Also check out the full Json.NET documentation if you aren’t familiar with it already).

The result of that insert will look like:

One more minor thing to point out: I used Guid.NewGuid().ToString() to create arbitrary keys for the documents. If you have value(s) in the XML data that you want to use for a key, you could/should use those value(s) instead.

This blog post was inspired by an email conversation with a Couchbase user. If you have any suggestions on tools, tips, or tricks to make this process easier, please let me know. Or, contact me if there’s something you’d like to see me blog about! You can email me or contact me @mgroves on Twitter.

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.