6 ms·

We already have json patch(http://jsonpatch.com/ http://jsonpatch.com/) and we can sent diffs as json patch document, so I don't understand what is the purpose

We already have json patch(http://jsonpatch.com/ http://jsonpatch.com/) and we can sent diffs as json patch document, so I don't understand what is the purpose of this proposal.

LukeEF 5y ago
TerminusDB person here: we were using the API internally for our immutable collaboration database service [1] so we thought we'd make it available for others to use. We think it is better than the one derived from the RFC and built specifically for collaboration, but you can be the judge of that! In any case - choice is good, right? [1] https://terminusdb.com/ https://terminusdb.com/
skrtskrt 5y ago
We also have JSON Merge Patch (https://www.rfc-editor.org/rfc/rfc7396 https://www.rfc-editor.org/rfc/rfc7396), and both have very little adoption (judging by the available libraries & integrations) I haven't used any of these yet, I've been waiting for one to obviously "win " and gain some support, but have definitely felt the pain. Use case: Sending a Kafka message to add or remove a value from an array field without having to know the rest of the array
- ninja_daro_yco 5y ago
  Actually we are using json patch/json pointer extensively to limit data sent through network or update live data on a client(its embedded world). If user is changing single parameter on a client we sent just json patch as defined in RFC(including arrays modifications). Libraries are mature and simple to use(on client, on server we are using C++ so I suppose its a in house solution), thats why it's hard for me to understand why we need another solution for the same problem. Having said that I haven't used them in Kafka world.
- Bjartr 5y ago
  For a(n anec)datapoint, I'm using JSON Patch in a production application.
  - erichocean 5y ago
    Same, works fine.
- smarterclayton 5y ago
  Kubernetes supports both JSON patch and merge patch, and it has been a continuous source of amazement to me (in the “that’s a bloody giant hole in the ground” sense) of how hard actually calculating, representing, and developing durable intuition about finding differences between and merging JSON-like trees (empty lists, null vs empty, representing insertion vs deletion, lists with primary keyed members, list uniqueness, field ordering, duplicate fields, number equivalence, etc). Add in defending against pathologically malformed patches - several vulnerabilities were discovered in the golang patch libraries Kube used - and one starts to develop a twitch whenever it is mentioned…
ggleason 5y ago
We use JSON-patch/diff internally for our rebase operation. We looked at implementing it on rfc6902 but it turned out to be awkward because of the path descriptions, and insufficiently rich for the kinds of patches that we needed. We could have extended rfc6902 but then we'd be in the embrace / extend / destroy pattern no?
- jsmith45 5y ago
  Yeah RFC6902 works best when you are only trying to create patches that are safe to apply to exactly the expected document. You potentially need much more for some scenarios where you could be applying a patch to a previously modified document. It has some limited support for some common operations for these, but quite far from everything that could be useful. But it is also true that they needed to put the limit somewhere, and where they stopped is reasonable for a fair few scenarios, but certainly not every possible one.

We already have json patch(http://jsonpatch.com/ http://jsonpatch.com/) and we can sent diffs as json patch document, so I don't understand what is the purpose of this proposal.

LukeEF 5y ago

TerminusDB person here: we were using the API internally for our immutable collaboration database service [1] so we thought we'd make it available for others to use. We think it is better than the one derived from the RFC and built specifically for collaboration, but you can be the judge of that! In any case - choice is good, right? [1] https://terminusdb.com/ https://terminusdb.com/

skrtskrt 5y ago

We also have JSON Merge Patch (https://www.rfc-editor.org/rfc/rfc7396 https://www.rfc-editor.org/rfc/rfc7396), and both have very little adoption (judging by the available libraries & integrations) I haven't used any of these yet, I've been waiting for one to obviously "win " and gain some support, but have definitely felt the pain. Use case: Sending a Kafka message to add or remove a value from an array field without having to know the rest of the array

ninja_daro_yco 5y ago
Actually we are using json patch/json pointer extensively to limit data sent through network or update live data on a client(its embedded world). If user is changing single parameter on a client we sent just json patch as defined in RFC(including arrays modifications). Libraries are mature and simple to use(on client, on server we are using C++ so I suppose its a in house solution), thats why it's hard for me to understand why we need another solution for the same problem. Having said that I haven't used them in Kafka world.
Bjartr 5y ago
For a(n anec)datapoint, I'm using JSON Patch in a production application.
- erichocean 5y ago
  Same, works fine.
smarterclayton 5y ago
Kubernetes supports both JSON patch and merge patch, and it has been a continuous source of amazement to me (in the “that’s a bloody giant hole in the ground” sense) of how hard actually calculating, representing, and developing durable intuition about finding differences between and merging JSON-like trees (empty lists, null vs empty, representing insertion vs deletion, lists with primary keyed members, list uniqueness, field ordering, duplicate fields, number equivalence, etc). Add in defending against pathologically malformed patches - several vulnerabilities were discovered in the golang patch libraries Kube used - and one starts to develop a twitch whenever it is mentioned…

ggleason 5y ago

We use JSON-patch/diff internally for our rebase operation. We looked at implementing it on rfc6902 but it turned out to be awkward because of the path descriptions, and insufficiently rich for the kinds of patches that we needed. We could have extended rfc6902 but then we'd be in the embrace / extend / destroy pattern no?

jsmith45 5y ago
Yeah RFC6902 works best when you are only trying to create patches that are safe to apply to exactly the expected document. You potentially need much more for some scenarios where you could be applying a patch to a previously modified document. It has some limited support for some common operations for these, but quite far from everything that could be useful. But it is also true that they needed to put the limit somewhere, and where they stopped is reasonable for a fair few scenarios, but certainly not every possible one.