Getting Wierd value in View Query "MQ==" instead of 1

Couchbase Server
1

After creating a simple view (in the screen shot)
im using the folowing code for simple incercemnt

cb.incr(key, { initial: 1, offset: 1 }, function (err, result) {
if (err) throw err;

});	// Node.js Sdk 1.2.4

the problem is, that the view result value is “MQ==” instead of 1 ( as expceted)
I would guess it somthing to do with encoding.
when i do the exact same operation ,
with a shorter key 41 length. everything acts good .
does the key length can affect the situation ?
Thanks in adavance

1152×996 83.4 KB

2

That’s because technically 1 is not a valid JSON document, so the backend think it is kind of BLOB, and sends it as base64 encoded to frontend.

$ echo "MQ==" | base64 -d
1

I can assure you that the SDKs handle it properly.

3

Yep , i understand , but the problem is in the viewquery engine as well
view

function (doc, meta) {
  var arr = meta.id.split(':');
  if(arr.length > 2 && doc > 2) {
  	emit(arr, doc);  
  }
}

this view comes up empty

“doc > 2” << == this fails cause doc variable is a string .
you can see in the screen shot in the top part the value of the doc is viewed correctly.
but still the view engine failes to parse doc correctly , i guess i can convert the string to in using js , but im not sure its the right way

4

you can check document encoding with meta.type == "base64" and then decode it using decodeBase64(doc).

Just like in my post about analyzing binary documents: http://avsej.net/2013/analyzing-binary-data-in-couchbase/

5

allright thanks a lot. it all make sense .
just last question ,
can i set the content type , when i first create the document ?
i did look at the source code of the sdk and couldn’t find any option.encoding property.
if i can create it with encoding . the view function will be much more effiecient.
any clue how i create a document with an encoding .

I did dive into to the sdk

 cb.incr(key, { initial: 1, offset: 1, format: 'utf8' }, function (err, result) {
        if (err) throw err;

    });

i tried the flag format ‘utf8’ but no luck

6

you can use cb.set(...) before cb.incr(...). Passing flags with initial is not supported by the protocol.

7

Thanks alot ,

i tried to enjoy cb.incr which is atomic , when i use cb.set and then cb.incr it is less efficient as .
Thanks alot i understand the topic.

Still there is an issue , which relates to the key length , as i mentioned before .
cb.incr works great when the key is around 40 charterer length .
when i use cb.incr on a longer key around 120 length. This doc.encoding changes , to BASE64 ( and the view engine has to decode the data into utf8 which is an uwanted overhead for each Indexing operation).