Setting deeper nested JSON objects as a String

This is more a question / thought for further enhancement:

The current client.jsonSet(key, Path.ROOT_PATH, object) assumes a PoJo as the object. I would like to have an additional method that is client.jsonSet(key, Path.ROOT_PATH, string) that bypasses the JSON serialization. There is a workaround that doesn’t feel intuitive that is to use client.jsonSet(key, Path2.ROOT_PATH, object).

[dmaier-redislabs]

Guess I didn’t describe it well enough. I am not talking about plain strings. I am talking about JSON strings. So a JSON object in its String representation. If I remember correctly this is how RedisJSON works natively. You pass a path and a string that represents the JSON, e.g. JSON.SET test $ '{ "value" : "strong"}.

So imagine something like the following:

strong = "{ \"value\" : \"strong\"}"
client.jsonSet("jsonStr", ROOT_PATH, strong);
assertEquals(strong, client.jsonGet("jsonStr"));

This would currently by design fail because of the built-in serialization/de-serialization, which uses the default Gson builder. I would like to use a custom serializer/de-serializer on the raw JSON strings, but this is not totally intuitive with the current implementation. As said, it’s more a developer experience/usability thing.

[dmaier-redislabs]

Here my 2 pence:

1. I think that there needs to be a way for the client to figure the version out and then behave accordingly. I think that we should make this as friction-free as possible for developers. The client could maintain some context dependent on which RedisJSON is running on the target side. This would also allow you to keep the same interfaces (on the side of the cient) if something behind the scenes changes (e.g., RESP version, format of the path, …)
2. From my point of view, the target users of Jedis are both, regular and advanced users. I see it more as a lower-level client library without sophisticated object-mapping baked-in. It would be nice to be able to easily ‘plug’ such object mappings/serializers ‘in’ when needed.

Let me please provide some context and explain what I did that inspired this ticket:

• I defined my data model first logically. This logical model is reflected via classes. My model has Persons. One person can be a friend of another person. So the Person class has a member ‘friends’ that has the type Set<Person>.
• Now there is typically a difference between a logical data model (the one the class diagram represents) and the physical data model (the one that is stored in the database). With the default JSON serializer I would end up storing each referenced person embedded to another person, but this is not what I want to store. Instead I would like to embed an array of user id-s for storage purposes.
• There are indeed multiple ways to achieve this. Either I wrap my Person class which represents the physical data model, or I deal with it at (de-)serialization time of Person objects. I decided for the second option because I was going to implement more a Repository pattern instead of a DAO one.

So my example app will be able to access the friends of a person as Person directly (because the repo returns a person), but behind the scenes the repo deals with a physical model that is realized with the help of a custom (De-)Serializer.

Bottom line: I think that it is not uncommon that developers might want to decide in a flexible way how data is stored vs. how it is logically accessed. In that case the built-in JSON (de-)serialization might not be good enough.