In RedisJSON 2.6 RESP3 support was added and with this came a frightening change which was the deprecation notice for "legacy paths".

This brings some problems to the table that were not covered in the changelogs that i think are crucial for users to know because they will break a lot of code when switching over to RESP3.

The problem

The main problem here is that when the deprecated paths get removed there will be no way to retrieve the information without it being wrapped in an array, and this gets worse if your root is an array, this also introduces an issue where commands such as JSON.GET default to $ instead of . and this is what will break a lot of code.

Let me exemplify what this translates to in code.

Base:

JSON.SET ObjectExample "$" '{ "a": 1, "b": 2 }'
JSON.SET ArrayExample "$" '[3, { "c": 4 }]'

RESP2:

JSON.GET ObjectExample

{
  "a": 1,
  "b": 2
}

JSON.GET ArrayExample

[
  3,
  {
    "c": 4
  }
]

RESP3:

JSON.GET ObjectExample

[
  {
    "a": 1,
    "b": 2
  }
]

JSON.GET ArrayExample

[
  [
    3,
    {
      "c": 4
    }
  ]
]

With that said, that is not the only problem getting rid of "legacy paths" will cause.
Another big problem is in the behavior of JSON.MGET

Using .

JSON.MGET ObjectExample ArrayExample "."

[
  {
    "a": 1,
    "b": 2
  },
  [
    3,
    {
      "c": 4
    }
  ]
]

Using $

JSON.MGET ObjectExample ArrayExample "$"

[
  [
    {
      "a": 1,
      "b": 2
    }
  ],
  [
    [
      3,
      {
        "c": 4
      }
    ]
  ]
]

There are also other commands that will get affected by this but i think this examples are enough to get my point.

While the addition of RESP3 is welcome the changes that came along are not that desired, while removing unnecessary features is good what we are seeing here is the removal of a core feature that will just leave users hanging with no choices.

If this doesn't get addressed i can see a lot of issues being opened in the future regarding it because its not what users want, users want to be able to get their data without any additional work, returning an array that will always be discarded is a waste of memory, bandwidth and performance.

The Solution(s)

With that said, I'm not saying that we should reverse de deprecation warning but instead that at least an alternative is given.

I was searching for a while on the JSON Path "spec" and it seems like there is not real standard that everyone follows and each one has their own twist or difference so i don't think we should sit here and start arguing that x spec says y and instead we should focus on a way to provide the feature that is being removed in another way because user satisfaction should be the priority over a "spec" that changes depending on what source you look at.

To find a solution we have to keep somethings in mind:

1. Do not change any of the current behavior
2. Do not break compatibility with pre-resp3 version
3. Do not overcomplicate something that used to be simple

The first idea that comes to mind would be allowing $* since this syntax resembles XPath just like the majority of JSONPath does. I think this is the simplest and fastest solution however there might be some complications that I'm not aware that could make this not viable.

One option that came to mind while writing this was to allow "top level" @ but it might interfere with RediSearch.

Talking about RediSearch we also have the option of adding something like RediSearch's DIALECT option but to instead control how $ will behave when alone, however this will most likely go against one of the points mentioned above.

Conclusion

I hope this gets addressed and i would highly appreciate that anyone who reads this gives their own honest opinion, i see this as something that both the community and the devs should agree on before changing so we don't run into the same problem again.