Live data from Hacker News

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

jsonpatch.com

1–10 of 112 posts

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

#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 performance vs. efficiency curve which is desirable in a lot of circumstances.

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

#3
For anybody working in the identity space, the SCIM 2.0 API for partial modifications is based on RFC 6902:

https://tools.ietf.org/html/draft-ietf-scim-api-12#section-3...

(SCIM is a set of specs describing a schema and a REST API for data exchange between identity providers, more or less.)

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

#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 things can go out of sync super fast especially if these documents are concurrently shared across devices/users/caches. We solved this by making arrays into sets, whereby the sets are index by either a value (string, number) or in the case of containing more objects, having those objects specify a unique key (e.g. ["someArray", {"myUniqueKey": uniqueValue}, "propertyInsideTheObject"]. We maintain an ontology to know which keys are unique, but because we encode it in the patch itself the underlying platform doesn't need to know that hierarchy... it can simply look at each document's "myUniqueKey" to perform the update.

Thus our patches are always idempotent unlike the proposal.

If anyone is interested in any of this being open sourced (we have it production-quality in scala, java (android), objc, and javascript) let me know at aaron@empiric.al. It's a pretty powerful stack that we've considered open sourcing before... a bit like having your own version of Parse/Firebase but with a nicer/easier API.

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

#8

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…

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.

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

#10

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…

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.
Post reply on HN