A core goal of the new Couchbase .NET SDK is improving the developer experience. We are working to achieve this goal in several ways:

• Reducing the number of steps (read App.Config “free”) required to get up and running with Couchbase and the Couchbase .NET client
• Providing a consistent, uniform interface across all Couchbase client SDK’s
• Exposing easy to use, flexible, powerful new ways of querying documents and unstructured data

This post focuses on the last bullet point: providing rich query API’s to Couchbase documents. Specifically, it deals with new View querying enhancements we are adding to the SDK’s to make it dead-simple for you to get YOUR data, how YOU want it!

Querying in Couchbase

The Couchbase lineage is strongly influenced by two different persistence implementations: a Key/Value database and a Document database. K/V stores give you high throughput and low latency, but at cost: lack of flexibility.

Document databases build on K/V store concept for storing documents using the key as the primary index, but then add additional features for secondary and composite indexing and most importantly, features for querying across a set of keys and aggregating or filtering the results by emitting pro

jections off the primary document. In Couchbase we use Views created from Map/Reduce functions and expose them via a REST API which clients the use to query their documents.

In Couchbase Server 3.0, we are providing a third way of accessing your data: N1QL, a SQL-like query language. We plan on exposing N1QL through ad-hoc queries and a LINQ, provider in the future – will cover this in depth in future posts.

New View Querying Syntax

For the new .NET client, we have developed a Fluent Interface abstraction around the View Rest API that provides an intuitive and natural way of accessing and querying documents. Here is an example:

Here we

are creating a Cluster object, which is an observer for config changes happening on the Couchbase Server cluster, and using it to open a bucket instance. Then we create a ViewQuery object passing “true” as a parameter, which indicates that we are working with a development view. Then we chain together a series of function calls which be used to generate are REST request using the fluent interface mechanism. The From(…) method specifies the bucket and design document to target and the View(…) method is the Couchbase View we are accessing.

After we construct are ViewQuery object, we pass it into the Get(…) method which will execute the REST request and then serialize the results to a dynamic type. The benefits of using a dynamic type here is that you do not have to have an explicitly typed POCO defined at compile time, which provides quite a bit of flexibility. Finally, we iterate through the rows and display the results.

Note that by the time the developer-preview is released, the explicitly cast to IViewSupportable will not be required and there may be a few other changes, like the requirement to pass the bucket name into the From(…) method.

Developer Preview!

You may have noticed that I mentioned DP in this post and yes, we have one planned, but are not publically announcing the date until a bit later this month or early next month.