#23 Added generating JsonPatch from two objects

[LordXaosa]

Implementing of feature #23
Works with any kind of arrays and objects of any complexity.
Example of use:

var obj1 = new SomeObject(){Name="test"};
var obj2 = new SomeObject(){Name="test1", TestProperty="test"};
var po = obj1.CreatePatch(obj2);//forward diff
var po = obj2.CreatePatch(obj1);//backward diff
var jp = new JsonPatch(po);
...

[gregsdennis]

Wow! Thank you so much for this!

A few things:

1. The notes below.
2. Please have a look at the formatting. There seem to be some indentation inconsistences.
3. Please add some tests:
   • simple checks for single operation changes that cover all of the operations the code handles (for both objects and arrays)
   • a few complex checks including multiple changes and JSON documents with multiple layers
   • a round-trip check that
     • creates the patches for each direction
     • apply the patch to the first, verify that you get the second
     • apply the reverse patch to the second, verify that you get the first again

[LordXaosa]

Please review changes according to your comments

[gregsdennis]

These tests aren't quite what I'm looking for. They should generate the patch and compare that to an expected patch.

public void Add()
{
    var initial = // initial model;
    var target = // target model;
    var expectedPatch = // explicitly create the expected JsonPatch object

    var actualPatch = initial.CreatePatch(target);

    Assert.AreEqual(expectedPatch, actualPatch);
}

This is a more typical unit test pattern.

[LordXaosa]

Well in most cases I'll agree, but what with complex objects? It's a bit hard to create large patch manually. By the logic if patch was correct so objects would be equal, isn't it?

[gregsdennis]

This comment is for all of the simple tests. I want to ensure that the patch operations are generated correctly. To do that you need to analyze the patch itself.

The more complex tests (e.g. the round trip) can stay as it is, but these simple ones need to change.

[gregsdennis]

I'm not sure what including this property is accomplishing. It seems to be making the tests a bit confusing.

[LordXaosa]

We use JsonDocument in our projects when we need some dynamic objects here. So I thought that it would be quite right to test this too.

[gregsdennis]

JsonDocument is tested implicitly becuase you convert objects to JsonDocument before generating the patch. I don't think this is explicitly necessary in the tests.

[gregsdennis]

I think I'd like to see the path represented as a JsonPointer here rather than a string. Check out JsonPointer.Create() and JsonPointer.Combine() for managing them. This would be a lot faster than going through parsing each time.

[LordXaosa]

I think I agree with Combine, but what with Create? It needs known type to perform, because it uses expression with exact type. In this case I can only use Combine+Parse but what the point if I have to use Parse anyway

[gregsdennis]

There's a non-generic Create that you can use as well that just takes segments (looks like I still need to define implicit conversions from ints and strings to segments).

https://github.com/gregsdennis/json-everything/blob/master/JsonPointer/JsonPointer.cs#L198

[gregsdennis]

I'm going to update the pointer code to include casts from int and string to segments to make creating pointers easier. You'll need to rebase on top of that. It shouldn't have any conflicts since it's in a different project.

[gregsdennis]

Same here.

[gregsdennis]

There are some static methods on PatchOperation that will help you build a JsonPatch object explicitly rather than having to type out the JSON.