-
Notifications
You must be signed in to change notification settings - Fork 3.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Setting deeper nested JSON objects as a String #2937
Comments
@dmaier-redislabs Let's check following example from our test suit:
It clearly sets a plain String by |
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. So imagine something like the following:
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 As you have already said, |
Controlling how the passed over object is handled via the path parameter is semantically not intuitive. A path has semantically nothing to do with how object is serialized or not. |
Is this statement after trying both RedisJSON V1 and RedisJSON V2 at the the same time? Paths do make difference on how json commands are handled. FYI, Path represents the json path of RedisJSON v1 and Path2 represents the json path of RedisJSON v2. |
Yeah, I got this now. Maybe I missed it in the documentation or it wasn't totally obvious. Most of the stuff here is more about usability. It could be just me, but I personally don't like this Path vs. Path2 class approach versioning purposes. Here what I experienced (usability-wise):
|
I feel you. We are all waiting for help in documentation and/or tutorial. There are a few bigger questions as well. Like:
|
Here my 2 pence:
Let me please provide some context and explain what I did that inspired this ticket:
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. |
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 isclient.jsonSet(key, Path.ROOT_PATH, string)
that bypasses the JSON serialization. There is a workaround that doesn't feel intuitive that is to useclient.jsonSet(key, Path2.ROOT_PATH, object)
.The text was updated successfully, but these errors were encountered: