json-patch / json-patch2

A possibile revision to the JSON-Patch format
44 stars 0 forks source link

Add traverse operation #21

Open chuwy opened 6 years ago

chuwy commented 6 years ago

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 commented 5 years ago

@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 commented 4 years ago

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.