dharmafly / jsonpatch.com Goto Github PK

Text of request for comments, number 6902。

This issue subsumes #58 and #59, to suggest that each patch carry a timestamp
of the format 2019.07.22。07:22 pacific, with varying-length segments to the left and right of the center 。divider.

This timestamp format would assist globally with synchronization efforts across devices.

For example, Redux-style interaction recording could be played back at real-time speeds, instead of the fixed-interval recordings that take place now:

https://drive.google.com/open?id=1idSfoVUs1mJmqONShOQ3IOuNFKWCbQ_2

If prefixed by an application-specific base64-encoded identifier, many applications can be simplified into streams of event logs.

If you're going to host the schema at http://json.schemastore.org/json-patch, it might be a good idea to add that URI as the id property so that it can be referenced by other schemata.

I've added this property into the Manatee.Json implementation.

Using integers as keys for JSON hashes is relatively common and often outside of a developers' hands when using 3rd party APIs.

It would be great if there could be escape option to ensure if I do:
{"op": "add", "path": "/customers/23", "value": {"name": "Foo", "account" : "barred"}}
I would always generate something like
{
...
"customers" : {
"23" : { "name" : "Foo", "account " : "barred"}
}
...
}

And not:
{
...
"customers" : [ null,null,null,..(19 nulls),..,{ "name" : "Foo", "account " : "barred"}]
...
}

Maybe using ~2 would be fine
So something like:
{"op": "add", "path": "/customers/~223", "value": {"name": "Foo", "account" : "barred"}}

This json patch standard is awesome. However it should also have a swap operation also imo.

Example:

json:
{
     myArray: [1, 2],
     myObject:{ a:1, b: 2},
     myString: "Testing"
}

patch:
[
     { op: 'swap', from: 'myArray/0', path: 'myArray/1' }
     { op: 'swap', from: 'myObject/a', path: 'myObject/b' }
     { op: 'swap', from: 'myArray/0', path: 'myString' }
]

new json:
{
     myArray: ["Testing", 1],
     myObject:{ a:2, b: 1},
     myString: 2
}

Hi,

I looked through your spec but all the examples seemed to assume I know the position of an item in an array. Is there a way to specify the path to an array item based on one of its values?

[{
  "op": "replace",
  "path": "/model/dataSources/[name='item1']/connectionString",
  "value": "Data Source=something1;Initial Catalog=another1"
}]

for this:

{
  "name": "SemanticModel",
  "compatibilityLevel": 1200,
  "model": {
    "culture": "en-US",
    "dataSources": [
      {
        "name": "item1",
        "connectionString": "Data Source=source1;Initial Catalog=catalog1"
      },
      {
        "name": "item2",
        "connectionString": "Data Source=source2;Initial Catalog=catalog2"
      }
    ]
  }
}

example object:

{
  "biscuits": [
    {"name":"Digestive"},
    {"name": "Choco Liebniz"}
  ]
}

Remove

{"op": "remove", "path": "/biscuits"}

Removes a value from an object or array.

Disclaimer: I apologize if I'm being stupid, but...
In my humble opinion the text doesn't clarify whether the example operation will remove the entire biscuits property (which would leave an empty object: {}) or if it will remove a single value from the biscuits array.

The SSL Certificate presented by the jsonpatch.com website does not include jsonpatch.com in the Subject Alternate Name list and is flagged by all major browsers as invalid.

I apologize if there is a better venue for JSON Patch related questions, but I have not found one yet.

I am working on a project where we have a large JSON document that we are passing back and forth from client to server via GET/POST. We were researching options to send partial updates and discovered RFC 6902 and various projects that implement the standard.

I posted a question on stack overflow, in regards to keeping the document on the client in synch with the document on the server but I have not received feedback.

I assume the client would need the full document to take advantage of libraries that provide diffs and generate the patch commands. It would then seem like one would need to apply the patch to the client document, send the PATCH to the server and execute the patch on the server.

Is this the pattern to follow, or are we missing something?

Some link to libraries are not working for example
https://github.com/MarketsWorld/json-patch-utils

I am pretty sure this is not the right channel but I couldn't find how to address this otherwise.

The RFC6901 specification looks very JSON-unfriendly, re-inventing arrays through escaped strings, easily error prone while manipulating any path in projects such just-diff.

A different proposal

A JSON pointer can be just an Array requiring zero special cases and granting type preservation.
Being an Array, a JSON pointer can be used also as generic JavaScript path pointer including the ability to have a Symbol as part of the key.

Examples

Given the following structure:

{
  "biscuits": [
    { "name": "Digestive" },
    { "name": "Choco Leibniz" }
  ]
}

Instead of having /biscuits/1/name as path to point at "Choco Leibniz" string, the path could be ["biscuits", 1, "name"].

Since a path can be specified to use integers when it comes to Array access, it's now never ambiguous to understand the structure.

An object with numeric entries will have these represented as strings, an Array will have these represented as integers.

{
  "biscuits": {
    "5": { "name": "Choco Leibniz" },
    "2": { "name": "Digestive" }
  }
}

Accordingly, to point at "Choco Leibniz" we can now use ["biscuits", "5", "name"].

Edge cases

Empty keys are allowed via [""] and at any level as in ["", 2, "", "name"].

Last item

Using the convention that an integer, if negative, means from the Array length, it is possible to point at a generic last item via -1, as example via ["biscuits", -1].

If the length of the array is meant, as appending at the end, being length an array property the path could simply be ["biscuits", "length"].

Improvements

• the pointer is a real JSON compatible structure itself, instead of a reinvented string with edge cases in core
• humans can both easily read and write manually, if needed, paths, without needing to learn anything new
• walking-through-the-path performances are better thanks to zero string manipulation needed and, in typed platforms, zero casting per object type needed too.

As typed array, JSON pointer would be a list/set that can contain either strings or integers.

As a wider solution, a JSON pointer could contain also JavaScript symbols which is a generic object key by all means, but this is out of current JSON Pointer scope/proposal.

Thanks in advance for any sort of outcome.

Hello @almost 👋

What are the plans for the future of this site? I'm asking because it's the first answer of Google but many of the libraries are long outdated or deprecated. Do you have any plans on accepting the pull requests?