Archive for the ‘CouchDB’ category

Error trying to run C# SDK for Couchbase

February 20th, 2013

If you are going through the tutorial on this page: Couchbase Tutorial and you get an error right off the bat trying to instantiate the CouchbaseClient with just a simple call like: var client = new CouchbaseClient(); then you probably have your app.config in the wrong order. Contrary to what they are saying on the couchbase site, refer to my config file below to get your stuff up and running correctly.

<?xml version="1.0"?>
    <section name="couchbase" type="Couchbase.Configuration.CouchbaseClientSection, Couchbase"/>
    <servers bucket="default" bucketPassword="">
      <add uri=""/>
    <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5"/>

The big gotcha is the where I had the runtime line placed, if I had it at the top, it would throw the error, but if you have it as I am showing here, it seems to work fine.

The PouchDb project is looking pretty good

February 1st, 2013

I along with a co-worker have been following the PouchDB project, HERE is a link to the project’s website. If you have been following some of my posts in the past, you know I have dabbled and used CouchDB quite a bit. One of the issues we ran into was when you want to post your documents right into a local couch say sitting on port :5984, you will run into a Cross Domain error, well, PouchDB seems to alleviate this issue by being a native JavaScript NoSQL solution, how sweet is that? The even sweeter piece to this puzzle is that it syncs right to a couchdb database natively, which is the icing on the cake for me. The big issue with PouchDB in the past was that it had a version of JQuery baked into it, which was causing any app I had that used JQuery to step on itself because of the multiple references, well, the guys working on that project have seemed to fix this problem, this tool is starting to look ready for the big time. I will update in the weeks to come some scenarios/examples of this in action.

Building CouchApps (My latest adventure)

June 7th, 2012

I have been working with CouchDB for quite some time as you may have seen in my past blog posts and after a lot of research I came across the idea of a CouchApp as described here: CouchApps The idea is simple, communicate with your database straight instead of using an application server like Rails or MVC, let the database be your storage and application server. So far so good, what I especially love about how they function is the deployment aspect of it, you can deploy your site as easy as opening up your command line and typing in “couchapp push”, it really is that easy. If you couple this with Backbone.js like with this connector: Backbone-Couch Connector you have a very clean and efficient webapp. I will make more posts about this in weeks to come as I am very excited about the things I am learning about it.

Similarities between Replication and Event or Message Bus

January 24th, 2012

A key component to many distributed software systems is the concept of a Message or Event Bus.  Any good Messaging architecture should be able to accomplish some basic things when it comes to transporting your messages, I have outlined them below:

  • Publish-Subscribe: Modules may subscribe to certain message types. Whenever a module publishes a message to the bus, it will be delivered to all modules that subscribed to its message type.
  • Broadcast: The message will be delivered to all (other) modules.
  • Point-to-point: The message has one and only one recipient.

In doing my research into distributed systems I keep wanting to do a comparison of these two techniques of transporting messages around in a distributed system.  At its very basic usage, replication takes care of the Broadcast scenario very easily, right out of the box, that is the very definition of replication.  The other two types Publish-Subscribe and Point-to-Point were simply not possible up until this point without a lot of application level logic, that just simply doesn’t make much sense.

Although CouchDB with its introduction of selective replication seems to accomplish this, I don’t want to focus this on Couch, I just want to pose Selective Replication as an alternative to using a message bus and I would like to see what the pros-cons are for each.  This is what prompted me to write the CouchDB admin tool, because when you have selective replication, you have a need to administer those replication documents and filters to tell the databases where the documents need to go.  I think that the admin tool is a drawback to using Selective Replication but on the flipside you will have a lot of code or configuration in the event bus system, particularly in the writing/maintenance of the many modules you need to get the publishers/subscribers in place.

I think a large pro in favor of Selective or Full Replication is how easy it is to make backups or replicas of your data, instead of having to pass your messages through the bus in the Message Bus system with replication you just bring your db online and it will do the replication for you, so there is a significant performance advantage in replication.

As far as Publisher-Subscriber messaging, this is where Filtered or Selective Replication comes into play, you have the ability to set up sets of filters that tells your database where to send the documents to and exactly which ones.  The Point-to-Point scenario is accomplished via this method as well, you just have a single point of replication, whether you choose to filter the documents is up to you.

I hope this document can be of use to somebody, I just wanted to get this out there for anybody else looking into options for building their next distributed systems.  I think both technologies have their advantages/disadvantages and should be used when they fit.

NCQRS Fork on GitHub

January 23rd, 2012

I noticed that the NCQRS project was missing a CouchDB event store example, so I created a project in the master NCQRS project that shows how you can hook into it using CouchDB, check out my fork at the address below.

Update on CouchDB Admin Tool

January 20th, 2012

I have included some screenshots of my new and improved version of the couchdb admin tool.  Upon further research I have noticed that CouchDB will only run a replicator document per target and source, meaning once you make one replicator document, if you make another and assign it the same target and source, it won’t ever kick that second one off until you change either the target or source.

In this new version I have busted out the UI into more tabs so it makes more sense.  I also created a DocTypeViewModel to model the replication documents you create over to the UI.  The code has been updated at

CouchDB Replication Admin Tool

January 16th, 2012

I whipped up this admin tool in WPF to show how you can manage users along with replication of your documents.  You will have to have the couchbase server installed before you can run the example tho, you can download that HERE   The code is pretty simple, the key is the redbranch-hammock library that I have been working with and modifying to my needs.  At this point the project is a WPF project, it would probably be better implemented as an site but I come from a desktop background and I was working with a local copy of couch on my machine so I went with a WPF project for now.  I will probably port it over to some sort of web project down the road later.   Here is the link to the google code SVN repository:

Filtered Replication Scenario for distributed systems.

January 10th, 2012

As you may know, I have been studying couchdb, specifically its ability to replicate your data and trying to get  a better understanding of how all this works.   I have modeled out the basic data flow for selective, or filtered replication of the data and I have attached the diagram below.  I will give a little bit of an explanation of what is going on here to hopefully make more sense of how things are going to work.

We have an admin tool that would most likely reside on a web server somewhere that will have the ability to do the standard CRUD operations on users as well as the standard CRUD operations on the couchdb documents for filtering the data.  Those changes will all go into a database that is housed on the main server on a per organization basis, say its your local store and the Master DB is your HQ.  That is the admin piece, now on to the server side..

The server, or Master DB will just be the central repository of data, the filters in my current idea will all sit in the Filtered DBs and we will let those filtered DBs make all the decisions on where the data goes when it comes to the server.

The client will have the full ability to create all the documents on the local or client side for simplicity at this point.  (I am defining the client as an actual application that will reside on the desktop, mobile device, whatever)  The Filtered DB will grab all the data from the client and hold it for filtered replication to the server later, this would seem to be a nice way to have a backup of your local data.  The idea at this point is to have the client side create the filtered DB on the server side which is simple enough via couchdb.

That pretty much sums it up, I have the diagram below.

CouchDB presentation @ StrangeLoop

January 9th, 2012

Here is a good little video of a presentation that Benjamin Young with CouchBase gave at the StrangeLoop conference.  If you are considering writing a couchDB app or migrating a current application you have to couch, I recommend watching this video, he gives a good rundown of the features of the NoSQL engine.

My first contribution to the open source world

January 9th, 2012

I have been working with an excellent library for CouchDB development called relax-net, located here:

After having some discussions with Nick, the creator of the library and overall really nice guy I found it was lacking some support for Replication and Replication Filters, so I took the time to write em and include that support into the library.  Thanks for including me in the acknowledgement Nick!!!

–UPDATE – I found that the code I committed into the project was not complete, when you add a replication document to the _replicator database, you have to make sure you are doing a POST instead of a PUT.  The current code was just placing documents in the system and not kicking any kind of replication off.