Wow was actually working on this with a friend at a previous job, glad to see someone has done it (and is trying to standardize).
JSON Patch – a format for describing changes to a JSON document
11–20 of 112 posts
Re: JSON Patch – a format for describing changes to a JSON document
#12I would love to know what the PostgreSQL developers thoughts are on this and whether this could be in the pipelines as an extension to their growing JSON support.
Re: JSON Patch – a format for describing changes to a JSON document
#13The thing you're competing against in terms of performance and efficiency is: 1. JSON.stringify() 2. Diff-match-patch: https://code.google.com/p/google-diff-match-patch/ 3. JSON.parse() There are several short-comings to the above approach though, specifically, you have to explicitly trade off performance vs. efficiency depending on the JSON you're dealing with. JSON Patch is going to give you a consistent performanc…
This is about sending a diff over the network without having to either have the full json document on hand, or worrying about other concurrent changes that might wreck the diff-match-patch. It's also json-aware versus operating on pure text which might lead to invalid json documents.
1. Errr, to apply any delta, including these, you need the document on hand.
If your goal is to store deltas, this is no better than anything else.
2. This is in no way better at handling concurrent changes than anything other diff format. In fact, the extra operations it has do nothing to help you here (it is as good and bad as copy/add, or insert/delete diffs). I'd love to know why you seem to think otherwise.
JSON awareness only helps when trying to apply partial patches. At that point, the only thing it can possibly buy you is syntactic correctness, which is worthless without semantic correctness (and in fact, sometimes worse)
Re: JSON Patch – a format for describing changes to a JSON document
#14The thing you're competing against in terms of performance and efficiency is: 1. JSON.stringify() 2. Diff-match-patch: https://code.google.com/p/google-diff-match-patch/ 3. JSON.parse() There are several short-comings to the above approach though, specifically, you have to explicitly trade off performance vs. efficiency depending on the JSON you're dealing with. JSON Patch is going to give you a consistent performanc…
I think you're missing the point. If I want to patch just one node and don't care what the rest of the document is, I cannot just use a text diff.
Can you explain why?
This seems like a trivial application of any copy/add delta format, which are easily expressed in text diff format.
Re: JSON Patch – a format for describing changes to a JSON document
#15The thing you're competing against in terms of performance and efficiency is: 1. JSON.stringify() 2. Diff-match-patch: https://code.google.com/p/google-diff-match-patch/ 3. JSON.parse() There are several short-comings to the above approach though, specifically, you have to explicitly trade off performance vs. efficiency depending on the JSON you're dealing with. JSON Patch is going to give you a consistent performanc…
Your proposed algorithm is a particularly poor solution in terms of correctness if nothing else. For text, DMP performs quite well- patches can typically be applied in arbitrary order with the same result. For complex data formats, you very quickly arrive at invalid (JSON).
Re: JSON Patch – a format for describing changes to a JSON document
#16We (Empirical) have implemented a similar couple years ago in our json-backed model. I see two big problems with this standard: 1. Why express paths as a string if you have the ability to encode it as an array in json? Otherwise you run up against the escaping problem for which they use ~0 and ~1 (of all things?!) which is only going to cause bugs. 2. Indexing into arrays is a problem in distributed computing because…
I love the idea of using an array. Sounds like arrest addition to the spec.
Re: JSON Patch – a format for describing changes to a JSON document
#17This is a great complement to the PATCH HTTP verb for RESTful APIs. It's much better to have a standard way to describe how a resource should be changed and not some ad hoc, implementation-specific syntax. Coincidentally, I just implemented support for this in one of my projects today (https://pypi.python.org/pypi/elita).
Here's a link to the original RFC from 2013: https://tools.ietf.org/html/rfc6902
A cool thing is the "test" operation. JSON patches are atomic, so you can put in something like:
{ "op": "test", "path": "/foo/bar", "value": 32 }
Re: JSON Patch – a format for describing changes to a JSON document
#18Earlier quoted context omitted.
I think you're missing the point. If I want to patch just one node and don't care what the rest of the document is, I cannot just use a text diff.
Can you explain why? This seems like a trivial application of any copy/add delta format, which are easily expressed in text diff format.
A simple example: if the order of the keys is different, say because of a different json implementation, semantically the document is identical, but you can't apply the patch anymore.
Re: JSON Patch – a format for describing changes to a JSON document
#19Seems like a good starting point, but it's a bit too simplistic for my taste.
"Add" seems like it's not idempotent as the existing value seems to change what it does.
Seems like a mistake to bundle array operations into "add" and "remove".
Array indexing is going to be useless for most applications because it makes assumptions about what's already there, and there is no way to specify fine-grained preconditions (or relativity such as "insert before the element 'b'").
No support for "increment", "decrement" or similar operations you'd want to make atomic.
No support for sets.
Unlike azinman2, I think paths as strings is fine. But why not support both? Let a path be either a string or an array.
Re: JSON Patch – a format for describing changes to a JSON document
#20Nice idea. However, what if we based it on MongoDB's syntax, for compatibility?
[
{ "$set": { "baz": "boo" } },
{ "$unset": { "foo": 1 } }
]