Skip to content
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

Add traverse operation #21

Open
chuwy opened this issue Jan 8, 2018 · 2 comments
Open

Add traverse operation #21

chuwy opened this issue Jan 8, 2018 · 2 comments

Comments

@chuwy
Copy link

chuwy commented Jan 8, 2018

I see it as a response on this old blog post: http://susanpotter.net/blogs/software/2011/07/why-json-pointer-falls-short/ (which is about JSON Pointer and querying, but for our use-case Patch and modifying is more important, nevertheless I'd be happy to hear about state of art for querying)

Basically, given this input array:

{
  "fooArray": [{"foo": 1}, {"foo": 2}, {"foo": 2}, {"foo": 1}],
  "nonArray": null
}

and following imaginary operation:

{
  "op": "traverse", "path": "/fooArray", "value": [
    { "op": "replace", "path": "/foo", "value": 42 },
  ]
}

would produce:

{
  "fooArray": [{"foo": 42}, {"foo": 42}, {"foo": 42}, {"foo": 42}],
  "nonArray": null
}

traverse here should roughly correspond to map (I like this name even more) from FP-languages.

@geryogam
Copy link

geryogam commented Feb 12, 2019

@chuwy No need to introduce a new operation. Your need could more simply and expressively be fulfilled with a simple array slice expression start:end:step in the path expression (see my recent proposal #23):

[
  {"op": "replace", "path": "/fooArray/:/foo", "value": 42}
]

@mitar
Copy link

mitar commented Oct 12, 2019

I prefer this over #23 because it does not modify JSON Pointers spec.

But it also looks very similar to #9. And similarly, I am against it because:

I would be against this proposal because I think this is premature optimization. These days it is easy to use some compression algorithm on top of the transport you are using for your JSON patches, which would make deduplicate such repetitions. I would not complicate the PATCH format itself.

So this proposal just changes that you do not have to write "/fooArray/0/foo" and so on many times. This can be compressed away.

And similarly to this comment, I think:

I feel this is going in the wrong direction and will make JSON patch be more and more like a programming language. I prefer to see JSON patch as a diff between known versions of JSON. Not a "program" to apply to unknown versions of JSON. The latter would then require more and more complicated logic. And how do we decide where it ends? Do you also want to define a function which computes the index at which to insert something? Or use regular expressions?

I think JSON patch should be for a fixed base JSON to apply to, and if the base JSON changes, another algorithm should determine how to try to fuzzy-apply the JSON patch, instead of making the JSON patch itself more complicated.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants