Salient Soft

So far when emitting multiple docs I have used arrayed keys containing ordinals to clearly define the order, as per this post here, where the key was complex and already arrayed.

In another example, I was just searching a view on a string ID and returning a couple of docs (via _include_docs), so I had the option of returning the same key for each doc, which is supported. This would allow me to search the view by key – if an arrayed key is used, then a range of start and end key is needed per the trick in the above post, otherwise not all the docs are returned.

In the end I stuck with the original arrayed pattern. Either way would need only a single pass through the B-Tree index. In addition, this recent bug report here seems to indicate problems in returned results when duplicate keys are present, so it looks like duplicate keys are best avoided. The arrayed pattern also gives deterministic order of documents in the results.

Comments Off on CouchDB view – duplicate keys vs arrayed keys

I had a bug whereby my view was emitting the same place document twice. This was strange as the database clearly did not contain 2 copies of the document. I had seen what appeared to be a similar issue before bud at the time did not track down the cause.

It turned out to be a bug in the view definition. The original (buggy) version follows:-

function (doc) {
  if (doc.type == ‘place’) {
      emit([doc.address.postTown, doc.address.locality, doc.name, doc._id, 0], null);
      emit([doc.address.postTown, doc.address.locality, doc.name, doc._id, 1], {_id: doc.placeFeaturesId});
  }
}

The problem with this is that when doc.placeFeaturesId is null/undefined, the second emit emits its key plus an “_id” with an undefined/null value in the generated json. The result of this is that when using ?include_docs=true to include the documents, CouchDB applies a default behaviour due to the null, and emits the place document again a second time. The following fix prevents the second emit when there are no placeFeatures present, which prevents the place document being emitted a second time. This solves the problem:-

function (doc) {
  if (doc.type == ‘place’) {
      emit([doc.address.postTown, doc.address.locality, doc.name, doc._id, 0], null);
      if (doc.placeFeaturesId) {
        emit([doc.address.postTown, doc.address.locality, doc.name, doc._id, 1], {_id: doc.placeFeaturesId});
      }
  }
}

The lesson here is to be careful to handle undefined or null values in the view code when emitting entries in a view definition as this can cause strange behaviour such as the duplicates above.

No Comments »

It is useful to enable CORS when using CouchDB for development, as this avoids the need for workarounds such as installing e.g. the CORS plugin in Chrome to bypass CORS issues.

As CORS is enabled/allowed on the Server Side, this needs to be enabled in CouchDB. This post details approaches to this. The easiest way (which is mentioned in the post comments) is just to do it in Fauxton. Just pick configuration on the left, and select CORS. You can enable for all domains (simplest for a closed development environment) or create a list. This github commit here can also do it but appears long winded compared to just doing it in Fauxton for simple cases.

No Comments »