Bob Browning's blog

When I began the project I am currently working on (more details will be provided next month – probably), it was initially intended as a small test to determine the capabilities of AI.  Over the last six months it has turned into something that we might take further. 

But I hit a problem. As a little hobby project I chose the database I really really like – CouchBD.  CouchDB is elegant, simple yet very functional and efficient. Close to the perfect database management system (DBMS).  But to take it further I need to involve other developers and it turs out that CouchDB skills are few and far between. Truly it is the Betamax of DBMSs.

So I decided to convert it to the more commonly used MongoDB.  Both of these DBMSs are NOSQL systems so conversion is feasible. I hit a few problem-ettes but  it has gone OK.  Here are some issues you might want to think about if you need to go the same way.

• Software
  Both CouchDB and MongoDB come with API functions. I have always routed database calls  through a central set of my own functions,  so all I need to do was convert these and I  was good to go. In a previous project I had developed functions for MongoDB, but If I had converted the routines from one to the other it wouldn’t be a big deal.

• Collections
  Since time immemorial database systems have had had the concept of ‘collections of data that are all about the same sort of thing’. Going back about 100 years we have: ‘Card decks’, ‘tapes’, ‘files’, ‘tables’ and now in the MongoDB world we have ‘collections’.  These words mean roughly the same thing.  
  
  CouchDB does not have this concept (gasp).  In CouchDB you don’t need this because the format and content of the ‘record’ ( ‘card’, ‘record’, ‘row’, ‘document’ – it is exhausting to keep up) are stored in the record. Every record on the database could have a different format and content. Which is liberating,  but not really that useful.  So CouchDB developers create  a field (same word for 100 years) called ‘type’, or something in every document to impose some order. In my case I called it ‘collection’.  
  
  I had a look at some conversion software and the ones I looked at  tended to make the whole database one collection on MongoDB. That didn’t seem a good idea. I just wrote a small program that just saved each ‘collection’ as a JSON file. Then used a handy program supplied with MongoDB to import each  JSON file into a separate collection I created first. The whole exercise was done in a morning – with time off for coffee.
  
• Record Key
  The next problem was the record key.  (sorry document key). Every record on every type of DBMS has to have  a unique key. In the good old days this was simply a number. The first record saved was number 1 the next 2 and so on.
  
  In CouchDB the key is a 24 byte mix of letters and numbers. You can use this type of key with MongoDB. But, as always, there is a caveat.  When you add a document to the database it generates a unique key which is an object. Which is bizarre. But you can convert the object to a 32 byte string and convert it back quite easily.
  
  So the database now has two formats for the key. One is a 24 byte string and the other an object.
  
  This is not the problem that it might be because my application use the 32 string equivalent rather than the object when passing it around. So the central software needed to have some code that turned a key that is a 32 byte string into an object but not a 24 bytes string.

So here I am. A simple elegant database system is replaced by an over engineered complex monster of a DBMS.  Happy days!