Using libcouchbase from C how to force JSON doctype

C SDK
1

I found this post: http://www.couchbase.com/forums/thread/question-regarding-c-client-library

But it didn’t solve my issue. I have many documents that are formatted as so:
{ “suffix”: [ 1133, 7108 ] }

Many times there are more numbers in the array (never exceeding about 20k bytes), but my problem is sometimes it will be set as JSON other times as binary and it seems arbitrary. I can flush and reimport a dozen times and different keys will be JSON versus binary almost every time.

How can I force the document always to be inserted as JSON. I looked at the code, it appears libcouchbase ignores anything we pass into the lcb_store_cmd_t.v.v0.datatype, which doesn’t have a definition other than uint8 (e.g. the examples show LCB_JSON which doesn’t exist from what I found). And based on the above link reference, my interpretation of the code is accurate and datatype is ignored.

So how can I, from C, force the document to always be JSON? I have to imagine it is something I am missing, or not doing as this seems to basic of an issue. Even if it is a format convention that makes it happen, I am fine with it for now, I just need to understand what I am doing wrong.

BTW – This seems to only happen if I have an array in the JSON document.

Thanks,
Mark.

2

I guess you are talking about how the view indexer is treating the doc, right?

are you sure all the docs are really valid JSON?

for example, this is valid JSON

{
    "suffix": [
        1133,
        7108   
    ]
}

but this one is not

{
    "suffix": [
        1133,
        7108,   
    ]
}

Does it happen always with the same docs?

3

Thank you for the reply.

Yes, I had validated our JSON, however, I am now questioning the 3rd party validator tool I used. Specifically in our data source, some values start like 0123, which we all know when type corrected to an int should be 123; but what I saw was they were being put into our array still as 0123 (effectively a string without quotes). However, the JSON validator says that is valid because it apparently ignores leading 0’s (totally my fault for not catching that).

I just found this during testing by removing the type conversion and just making the array an array of strings, at which point every document went in as JSON properly. My type conversion/error handling from string to int was faulty, leaving leading 0’s in there, in which case it would output 0123 and then libcouchbase would say that it wasn’t valid JSON and properly treat it as non-json. After fixing that, I now get proper values/JSON all the time.

I am good now though and do appreciate the response.

I am still confused about the variability I saw, because it wasn’t consistent every time, but I am chalking that up to my bad type conversion and the fact its been a while since I have written straight C.

Thanks again.

4

If i understand correctly your problem was related to your application code and JSON serialization of some values.

Regards
Tug
@tgrall

5

Correct. It was my code, stupid mistake on my part.

Issue was I have some values like 0123, my conversion to int so it would remove the leading 0 was failing silently so what got added to my json was 0123. Sadly I was using a JSON validator that didn’t catch it as invalid JSON.

e.g. as you know – [0123, 1234] is invalid, [“0123”, “1234”] is good and so is [123, 1234].

Thanks for checking in on it.