Getting deeper nested JSON objects as String

[dmaier-redislabs]

This is also not a bug, but more a potential usability improvement.

I would like to be able to get the result of client.getJson as a String in order to use a customer deserialization method.

A related question Why does client.getJson(key, Path.ROOT_PATH) return a Gson LinkedTreeMap, but client.getJson(key, Path2.ROOT_PATH) returns an org.json.JSONArray? It seems that we use two different libraries for Json representations here. Is this by intention? Can I influence the result deserialization somehow by plugging my own deserializer in?

[sazzad16]

@dmaier-redislabs Let's check our test suit:

jedis/src/test/java/redis/clients/jedis/modules/json/RedisJsonV1Test.java

Lines 38 to 39 in 3590438

	client.jsonSet("str", ROOT_PATH, "strong");
	assertEquals("strong", client.jsonGet("str"));

When we set a plain String using jsonSet, we are getting a plain String using plain jsonGet. Again I am really confused what are you missing and/or asking for.

[sazzad16]

@dmaier-redislabs For the second part of your question:

org.json is found out to be simple but the best solution to support RedisJSON V2.

As for Gson, the idea was brought from JRedisJSON where the approach to support RedisJSON V1 was decided several years ago.

[dmaier-redislabs]

1. Sure if I just set a JSONElement that is a String, then I get a String. If I got it corrctly this because my JSON contains then no nesting, but a JSONElement that is that String. So this doesn't address my problem. The ask is to set a JSON object that is deeper nested, but then return the object in its String representation. Why? Simply because I think that I am not the only one who would prefer to use a custom JSON deserializer.

2. OK, so GSon is legacy? So Path2 refers to v2 of RedisJSON v2? I would expect that both Gson and org.json are fully JSON compliant (https://www.json.org/json-en.html). I found it just confusing to deal with two JSON libraries when using the client library.

[sazzad16]

Consider

• <T> T executeCommand(CommandObject<T> commandObject) method - where you can provide your deserializer as Builder<T>.
• Object executeCommand(CommandArguments args) method - where you receive just the response from server and you can apply your deserializer on it.

[dmaier-redislabs]

Yeah, but it's not really good usability to refer to a very general low-level method. Is your solution applicable to getJson(...)?

[sazzad16]

it's not really good usability to refer to a very general low-level method.

Aren't you looking for something low-level anyway? I get that it's even lower than your expectation but you won't always get what you want. There would trade offs.

Is your solution applicable to getJson(...)?

I don't understand your question. What/Where is getJson(...)?

[dmaier-redislabs]

It's fine. I am getting that there is no way to pass the builder to the high-level method. Usability-wise it would be enough to retrieve the result a JSON string (stringified JSON, not a String property). This seems to be the case with Path2. Again, this is all about usability. It was just not totally obvious to me when/why to use Path2 vs. Path. I didn't associate it to the version. So is it expected that developers use from now on (with the new RedisJSON version) always Path2, and Path will no longer be used in the future?

[sazzad16]

It entirely depends on the RedisJSON.