Live data from Hacker News

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

jsonpatch.com

101–110 of 112 posts

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

#101

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.

You are correct, but if you control the environment enough to be doing this at all, then you control the environment enough to get the serialization consistent: either by having ordered dictionaries in the language a la Python and PHP, or implementing your own, or by sorting the keys lexicographically a la bencode.

That is, `diff(sorted_json_stringify(json_parse(p)))` will be adequate if `diff(p)` is not.

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

#102
Would anyone be willing to explain when this is used? I'm a little confused, is this format for patch updates from the client to the server? If so, then I assume it's for NoSQL db's that have deep documents, so that you know what part of the document needs to be updated... do you currently have to send the entire document in a patch? Are there client side model libs that will track object changes and format output in this way for the patch request (the js libs listed on the page look pretty low level)? Or am I misunderstanding this entirely...

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

#103
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…

We also faced this problem at work a while back, although, for XML.

My first iteration was similar in spirit to jsonpatch: a sequence of ops against the document. A XML patches grew things because mighty unwieldy and confusing. The maintainability of "diff operations" is incredibly low.

What I did in my second iteration was to have the patch document "look" like the document you are trying to create. Here's a document that will give you the general gist of how it worked (it's somewhat hard to describe in words): https://gist.github.com/jcdickinson/57e3a7e481a7e79f90b4

There are some operations (foreach, etc.) that I haven't included in the sample that are designed in an "operation" manner for scenarios where the structural approach won't work.

Either way it makes patches a lot more manageable and you may want to consider using it as inspiration. I included something rough in the gist to get the grey matter rolling.

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

#104

Earlier quoted context omitted.

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.

There are plenty of textual tree delta formats too.

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

#105
post #37

Earlier quoted context omitted.

Can you explain why? This seems like a trivial application of any copy/add delta format, which are easily expressed in text diff format.

Text diff is based on surrounding lines, specifically, siblings, parents, and children in this case. In JSON Patch, only the parents matter.

So then it's a bad implementation of a textual tree diff algorithm .... which again, is a standard copy/add delta format (with a small amount of metadata).

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

#106
post #86

Earlier quoted context omitted.

How else would you store it? Javascript Object Notation is text. Other formats such as BSON are different. Or are you simply talking about javascript style object literals?

JSON is external representation of objects. You can store the actual data on server in any form you like. Doesn't mean you have to store them in text.

But its Javascript Object Notation - Notation in this case implies text - if your storing it in something other than text it's not JSON.

From Wikipedia: JavaScript Object Notation, is an open standard format that uses human-readable text to transmit data objects consisting of attribute–value pairs.

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

#107

Having the paths in ever operation seems needlessly verbose. If I had an object { id name, password, email, phone } And I wanted to replace the email and phone items would I need to go: {"op": "replace", "path": "/user/0/email", "value": "new@email.address"} {"op": "replace", "path": "/user/0/phone", "value": "+64 4 555 5555"} If I have big objects then that is going to be allot of information to transport, something…

Why? A compression algorithm will remove that verbosity better than a more complex format will. Just use gzip on your HTTP and you're done.

Still compressed its going to be bigger. The other thing is its going to be more efficient for the processor if we define where in the object we are going to be working rather than navigating through the object for every single change even if they are adjacent to each other.

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

#108

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…

Considering how basic this is you wouldn't even really need a standard.

jQuery basically already has support for this exact thing, and it's only a few lines of pure JS.

$.extend({a:'b', b:2, c: [1,2]}, { a: null, b: 0})

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

#109

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…

Considering how basic this is you wouldn't even really need a standard. jQuery basically already has support for this exact thing, and it's only a few lines of pure JS. $.extend({a:'b', b:2, c: [1,2]}, { a: null, b: 0})

Of course it'd be hard to insert an item into that array...

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

#110
post #86

Earlier quoted context omitted.

JSON is external representation of objects. You can store the actual data on server in any form you like. Doesn't mean you have to store them in text.

But its Javascript Object Notation - Notation in this case implies text - if your storing it in something other than text it's not JSON. From Wikipedia: JavaScript Object Notation, is an open standard format that uses human-readable text to transmit data objects consisting of attribute–value pairs.

Like you pointed out JSON is used to transmit data objects, but storage of data objects on the server or local file is entirely different story. I hope I don't have to explain further.
Post reply on HN