Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JSON Patch – a format for describing changes to a JSON document

jsonpatch.com

Post reply on HN
Print view View original

71–80 of 112 posts

Re: JSON Patch – a format for describing changes to a JSON document

#71

Post by tiglionabbit »

Dashron wrote: post #40
drderidder wrote: post #34

This spec has come up a couple times; the first time I wondered whether a simpler approach might be acceptable: * setting properties to be updated * omitting properties to be unchanged * explicitly setting 'undefined' properties to be deleted I've used that approach and github seems to have done something similar. I like the idea of a patch spec for JSON - it's required by a strict implementation of REST with HTTP PA…

This proposal is more in line with the system you describe (except null instead of undefined). https://tools.ietf.org/html/rfc7386 I prefer it, and think it's much easier to understand.

I like it, but it's easy to get unintended results if you aren't careful. For example: https://gist.github.com/nickretallack/e0c17b338ee8bda2b67e

If you start with original.json, then client 1 applies add-middle-name.json, and then moments later client 2 applies change-name.json not knowing that the other patch had been applied, you'll end up with a possibly unintentional merging of the two. I'm assuming change-name here wanted to clobber the whole name object, and did not intend to merge and keep the middle name.

There's a couple ways around this. One is to code defensively and always pass the middle:null when clobbering the name, since you know other clients could set a middle name. The other is to do some sort of versioning check to ensure no one else has changed the document since you last fetched it. That could be implemented outside the json patch, using if-not-modified headers or something, though it is tempting to do it with the "test" actions provided in the main spec discussed here.

Re: JSON Patch – a format for describing changes to a JSON document

#72

Post by espadrine »

DonHopkins wrote: post #46

Google Wave did something like this. What protocol did they use to update JSON, and is it modular and can stand on its own, without all the other Wave stuff? Does anyone know what its features and drawbacks were?

I'll help you, but you should know that what they do is nothing like that. They used Operational Transformation. They have convergent properties which guarantee that you won't ever have merge conflicts. They also have, depending on the implementation, certain causality guarantees that ensure that what you edited stays the way you intended.

The basic idea is that you receive operations that modify your local operations. The challenge is in writing the function that takes each two operations and mutates them. Therefore, the protocol is of no practical interest, it simply serves that function's purpose.

Here's a set of libraries that implement this for strings: https://github.com/Operational-Transformation

Implementing this for JSON is certainly possible, and has been done. See this for instance: https://github.com/share/ShareJS

Re: JSON Patch – a format for describing changes to a JSON document

#73

Post by icebraining »

andrewstuart2 wrote: post #39
drderidder wrote: post #38

Earlier quoted context omitted.

I might misunderstand your comment but FWIW, buried in RFC 5789 the description of PATCH calls for a "description of changes" to be sent, so JSON Patch is trying to define a format for the set of changes to meet the requirement for using PATCH (and implementing REST) correctly. Still, JSON Patch is just too clunky compared to the elegant simplicity of JSON itself, IMHO.

I definitely agree that it's a bit too clunky. I think it's arguable though that PATCH itself isn't quite RESTful as it doesn't describe the state of a resource at the identifier, but instead some subset of the state of that resource. Doing that kind of destroys the semantics of the resource identifier. You'd probably still find me arguing for PATCH as it's obviously preferable not to resend an entire resource to ref…

I think it's arguable though that PATCH itself isn't quite RESTful as it doesn't describe the state of a resource at the identifier, but instead some subset of the state of that resource. Doing that kind of destroys the semantics of the resource identifier.

Can you expand on that point? I'm not clear on how would it affect the semantics of the resource identifier.

Re: JSON Patch – a format for describing changes to a JSON document

#74

Post by ecksor »

Anyone interested in this (JSON patch, CRDTs, operational transforms etc), should definitely take a look at ShareJS: https://github.com/share/ShareJS

There's been some discussion recently on the wave-dev list: http://mail-archives.apache.org/mod_mbox/incubator-wave-dev/...

Re: JSON Patch – a format for describing changes to a JSON document

#75

Post by almost »

drderidder wrote: post #34

This spec has come up a couple times; the first time I wondered whether a simpler approach might be acceptable: * setting properties to be updated * omitting properties to be unchanged * explicitly setting 'undefined' properties to be deleted I've used that approach and github seems to have done something similar. I like the idea of a patch spec for JSON - it's required by a strict implementation of REST with HTTP PA…

This is what people often do apart from the last point (no undefined in JSON, and by definition anything you could choose here would conflict with valid values). This works well for a lot of use cases but can't express everything you might want to do with something like JSON-Patch.

Re: JSON Patch – a format for describing changes to a JSON document

#76

Post by almost »

drderidder wrote: post #34

This spec has come up a couple times; the first time I wondered whether a simpler approach might be acceptable: * setting properties to be updated * omitting properties to be unchanged * explicitly setting 'undefined' properties to be deleted I've used that approach and github seems to have done something similar. I like the idea of a patch spec for JSON - it's required by a strict implementation of REST with HTTP PA…

This is what people often do apart from the last point (no undefined in JSON, and by definition anything you could choose here would conflict with valid values). This works well for a lot of use cases but can't express everything you might want to do with something like JSON-Patch.

Re: JSON Patch – a format for describing changes to a JSON document

#77

Post by almost »

chj wrote: post #6

The op missing is string diff. If a very long string value has changed, no matter how little the change is, you'll have to include the entire string in the patch.

That would be really useful for some things. Quite a burden to put on the library implementors though!

Re: JSON Patch – a format for describing changes to a JSON document

#78

Post by nhaehnle »

mikeknoop wrote: post #2

The 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…

It is my understanding that the JSON encoding of objects is not specified canonically because the order of keys can be arbitrary. That is, JSON.stringify() is free to return different strings for the same JSON object.

Is my understanding correct? If it is, that would totally break your suggestion.

Re: JSON Patch – a format for describing changes to a JSON document

#79

Post by kosinus »

We built a similar JavaScript library to create and apply JSON patches: https://github.com/Two-Screen/symmetry

The format is not formally specified in any way, but it looks like the biggest differences are that we 1) make a distinction between object and array operations and 2) don't encode paths, but instead nest patches.

In practice, we found our JSON structures are never deep enough for nesting to a problem. To save space on the wire, our patch object has single character keys, such as `s` for set, `r` for remove, etc.

It looks like these libraries don't actually create patches? Symmetry has routines to diff between two objects, and implements Myers' algorithm for array comparisons. (Already fast, but can be further optimized.)

On the other hand, Symmetry doesn't have copy, move or test operations. Those are interesting.

Re: JSON Patch – a format for describing changes to a JSON document

#80

Post by afandian »

jasonkostempski wrote: post #36
azinman2 wrote: post #7

We (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…

Damn, thought I invented the array path thing :) I love how clear it is to read but my favorite thing is how easy it is to apply it: var x = { a: 1, b: 'B', c: { x: "X", y: "Y", z: "Z" }, d: [{p:"P"},{q:"Q"},{r:"R"}] }; ["d", 1, "q"].reduce(function (prev, curr) { return prev[curr]; }, x); >>> "Q" I got stuck at indexing as well. I feel like there's a good solution involving using an array element within the path arr…

If you're interested, this is the general structure and access method of the 'trie' data structure.

http://en.wikipedia.org/wiki/Trie

Also, Clojure has a nice functions called get-in and friends:

    user=> (def x {:a 1 :b 'B' :c { :x "X" :y "Y" :z "Z" } 
                   :d [{:p "P"} {:q "Q"} {:r "R"}] })
    #'user/x
    user=> (get-in x [:d 1 :q])
    "Q"
    user=> (assoc-in x [:d 1 :q] "QQ")
    {:a 1, :c {:z "Z", :y "Y", :x "X"}, :b B', :d [{:p "P"} {:q "QQ"} {:r "R"}]}
Post reply on HN