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

21–30 of 112 posts

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

#21

Post by chj »

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…

Seconded.

Paths as array is a much better way than escape codes. That would save people a lot of time in explaining and understanding, especially if this is going to be standardized.

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

#22

Post by chj »

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…

JSON data is not always stored as texts.

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

#23

Post by rpedela »

chris-teague wrote: post #12

I 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.

I proposed this feature a few months ago. I am not sure if anyone is working on it though.

http://www.postgresql.org/message-id/CACu89FSYikxdUj+J01BoAv...

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

#24

Post by verroq »

DannyBee wrote: post #14
kolev wrote: post #10

Earlier 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.

Because you may not want to serialise your data. Because the order of a json dictionary key is undefined.

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

#26

Post by oneeyedpigeon »

lobster_johnson wrote: post #19

Seems 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 r…

Surely supporting "increment"/"decrement" would break idempotency?

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

#28

Post by andrewstuart2 »

As long as they don't try to call it RESTful I think it's a good idea.

On the other hand, if HTTP/2 can minimize the overhead of just making many consecutive HTTP calls, that feels a lot better to me than using what is essentially a constrained RPC interface.

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

#29

Post by skybrian »

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…

That's absolutely true about arrays but maintaining on ontology isn't a general-purpose solution for arbitrary JSON. Perhaps a simpler solution that applies patches to a known document in a specific order will still be useful in some cases?

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

#30

Post by function_seven »

DannyBee wrote: post #13
azinman2 wrote: post #8

Earlier quoted context omitted.

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…

> 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.

Doesn't this allow the sender to send updates without knowledge of the existing values, though? With a string diff, the existing value would have to be known.

> 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.

If you're sending a regular diff, you would clobber changes to other parts of the object if they were updated between your initial retrieval and subsequent change. But yeah, it doesn't seem to help with applying concurrent changes to the same part of an object, though I don't know if the patch format should shoulder that responsibility.

Post reply on HN