Unable to decode JSON document, returns flag 0x112


#1

We’re trying to retrieve certain JSON documents from Couchbase but we’re getting the following error:

Flags (0x112) indicate non-JSON document

Any idea why this error is occurring? We’ve made sure that the value of the document is valid JSON.


#2

How was the document set/added?

Quick summary is that current Couchbase SDKs have an agreed upon value for flags that indicate datatypes such as JSON, but legacy Couchbase SDKs may not and other components may not. Full details are behind the “common flags” link in the list of specs on the wiki.


#3

I’m not sure when or how the document was set/added. According to what I’ve found while looking up information about this issue, it looks like it was probably added using the .NET 1.x.x client. Is there no way to just get this document as a string or maybe even binary using the Java 2.x.x client? We simply just want the ability to query this document to see what’s in it.


#4

The way to get it is to use a custom transcoder. It was in the “2.x SDKs” (in quotes because go-lang for instance was net-new, so it was a 1.x) that we standardized the flags and transcoder handling. The legacy was inherited from various open source memcached projects and we devised a way to be compatible with the legacy but move toward consistency.

In the legacy, .NET and Java didn’t inter-operate. Since you have one foot in both worlds (.NET 1.x and Java 2.x), you’re seeing this.

Interestingly enough, this just came up in another thread here on the forums in recent days:

The example there from @unhuman is, as I mention in the thread, not so much of a hack as an intended part of the interface for extension. A transcoder can be configured to convert your .NET legacy documents into whatever’s appropriate here in the Java 2.x SDK.

You might ask why we don’t do that automatically? The problem is the legacy and open source memcached clients have varying behavior. There’s no way we can automatically figure it out, unfortunately.

You need to know a bit about what created the document in order to unpack it correctly. Or, you need to duck-type-transcode it, which is too expensive from a performance perspective.

The good news is that if you’re all in the future, everything interoperates great and if you have one foot in the past we still have an interface (the transcoder) that lets you do what you need to.