The Transcoder API was redesigned in SDK3; its now much more specialized and this type of conversion doesn’t work with the default JsonTranscoder. Fortunately, we do have another transcoder which mimics the sdk2 behavior called the LegacyTranscoder which should be able to handle this for you.
Note there is a patch and should be available in 3.0.8 release next month.
After much thought, I think the JsonTranscoder is working as expected; you can mix and match any of the other Transcoders for your use-cases or write your own if you have a corner case not covered by the ones that come with the SDKs.
I have just posted a thread, on this exact subject (not sure why I didnt see it in the suggestions, but nevermind).
However, I think that the solutions presented here are way to convoluted/complex. It is not clear to me why Newtonsoft JSON should be involved when I clearly specify that I want a string, and nothing else. LegacyTranscoder or not, the data should be parsed as a string and returned, without a developer needing to to complex workarounds.
Can I suggest that you update the SDK so transcoder options are not necessary?
If you’d like to operate in such a model, feel free to configure your cluster to use the LegacyTranscoder globally. This transcoder is compatible with the 2.x SDK approach, which did do things like you are suggesting.
The new approach is to vastly simplify the transcoder operations. During the 2.x SDK phase, it was determined that the LegacyTranscoder approach was creating more confusion, not less. For example, if I’m reading/writing strings, should they be JSON encoded with double-quotes and backslash escaping, or not? There was no clear way to indicate one situation or the other, the LegacyTranscoder was forced to make assumptions that may not be accurate for all use cases.
The new approach is to have the JsonTranscoder assume that any type you send it is meant to be encoded as JSON, as clearly indicated by using the JsonTranscoder. If you send it a string, it will assume it’s wrapped in quotes and escaped as JSON. If you send it a byte array, it will output it as a JSON array of numbers. This provides a clear and understandable way of handling the data to and from the server which is consistent across SDKs from all development platforms. Other behaviors like directly decoding strings without escaping or reading raw binary data are also supported using alternative transcoders like RawStringTranscoder and RawBinaryTranscoder. This is more expressive than the previous LegacyTranscoder approach, allowing the developer to specify which way they want the type to be serialized/deserialized (as JSON or raw) rather than always assuming raw.
Thanks for the answer and reasoning behind, appreciated.
So, I then assume that nothing is saved as “strings” in Couchbase, but in some other format, and to get a string requires some translation of the underlying persistance format, and thus, you need to specify how that string is created from whatever-format-couchbase-is-using-under-the-hood?
Basically correct, everything is stored in Couchbase as binary data. Though Couchbase does recognize UTF-8 encoded JSON (by far the most common) to provide functions like indexing and querying. This is typically indicated by the transcoder by applying a JSON data format flag when persisting.