EncodedJsonContent?

In the 3.0 Java SDK howto, reference is made to EncodedJsonContent. However, I can’t find this anywhere either in the Couchbase SDK or through google. Has it not been implemented? Has its name been changed? Or am I just not looking hard enough?

@gareth apologies, some of this is has been in flux and is in the process of being updated. If you want to pass around raw json you can do it like this:

collection.upsert("my-id", "{....}", UpsertOptions.upsertOptions().transcoder(RawJsonTranscoder.INSTANCE));
collection.get("my-id", GetOptions.getOptions().transcoder(RawJsonTranscoder.INSTANCE));

It not only works with strings, you can also pass the byte arrays as a value. Note that you can also use the raw types for subdoc and n1ql queries too now:

QueryResult result = cluster.query("select 1=1");
for (byte[] row : result.rowsAs(byte[].class)) {
  System.out.println(row);
}

Thanks. I think that makes sense and I’ll have a play with it.

I don’t think I want to use “my own transcoder” as such, but to have a POJO-like API from which concepts such as JsonObject do not “leak”. It seems that you are trying to do something very similar here and I was curious to see how good a fit it was.

@gareth are you using jackson for your stuff by chance? I think this made beta.2: https://github.com/couchbase/couchbase-jvm-clients/commit/6fe812e6b3498fc3dde7d3f724cdd7feae20f7ea

If the SDK now finds an un-shaded jackson on the classpath it will use that one for serialization, which means that you should be able to read and write your POJOs with your own jackson annotations etc. directly from the API. If you use a different mechanism, creating your own transcoder is one possibility, but just dealing with raw in/out as mentioned above is an easy way to go as well.

Well, right now I am using JsonObject and it is leaking. And using SDK 2.0 the worst thing was that it was leaking across to code I wanted to share between server and mobile so I had a messy abstraction to get rid of that. I’m in the process of trying to clean that up by removing all awareness of JSON from the API and replace that with a layer which can do the conversion from POJOs to Json closer to the wire.

What you are doing sounds incredibly similar to that so seems like a good fit, but given that the calls to the Couchbase API are also going to be hidden, I will probably just convert to JsonObjects just before doing the write internal to my own classes.

For efficiency reasons it can make sense to go straight from POJO via jackson or similar to byte and store/read it. (JsonObject would just be a garbage middle man in this case). Also note that in SDK 2 a similar thing is available: RawJsonDocument - that allows you to read and write encoded JSON without the overhead of re-encoding with JsonObject.