Fix for diffing using iterable_compare_func with nested objects.

[dtorres-sf]

@seperman we have been using deep diff with the iterable_compare_func I helped add a little while back and we ran into an issue with nested objects. If you had an iterable item that moved, and then it had a nested iterable item that got objects added - it was incorrectly merging those objects. So something like:

        t1 = {
            "TestTable": [
                {
                    "id": "022fb580-800e-11ea-a361-39b3dada34b5",
                    "name": "Max",
                    "NestedTable": [
                        {
                            "id": "022fb580-800e-11ea-a361-39b3dada34a6",
                            "NestedField": "Test Field"
                        }
                    ]
                },
                {
                    "id": "022fb580-800e-11ea-a361-12354656532",
                    "name": "Bob",
                    "NestedTable": [
                        {
                            "id": "022fb580-800e-11ea-a361-39b3dada34c7",
                            "NestedField": "Test Field 2"
                        },
                    ]
                },
            ]
        }

        t2 = {"TestTable": [
            {
                "id": "022fb580-800e-11ea-a361-12354656532",
                "name": "Bob (Changed Name)",
                "NestedTable": [
                    {
                        "id": "022fb580-800e-11ea-a361-39b3dada34c7",
                        "NestedField": "Test Field 2 (Changed Nested Field)"
                    },
                    {
                        "id": "new id",
                        "NestedField": "Test Field 3"
                    },
                    {
                        "id": "newer id",
                        "NestedField": "Test Field 4"
                    },
                ]
            },
            {
                "id": "adding_some_random_id",
                "name": "New Name",
                "NestedTable": [
                    {
                        "id": "random_nested_id_added",
                        "NestedField": "New Nested Field"
                    },
                    {
                        "id": "random_nested_id_added2",
                        "NestedField": "New Nested Field2"
                    },
                    {
                        "id": "random_nested_id_added3",
                        "NestedField": "New Nested Field43"
                    },
                ]
            }
        ]}

Merged the items in the t2 nested tables like this rather than splitting it across the item that was moved.

{
  "TestTable": [
    {
      "NestedTable": [
        {
          "id": "random_nested_id_added",
          "NestedField": "New Nested Field"
        },
        {
          "id": "new id",
          "NestedField": "Test Field 3"
        },
        {
          "id": "newer id",
          "NestedField": "Test Field 4"
        }
      ],
      "id": "adding_some_random_id",
      "name": "New Name"
    }
  ]
}

You can see these objects in the new test that was failing without these changes.

I have put comments on the two main changes describing them a bit more.

[dtorres-sf]

This change ensures that all indexes in the resulting diff are relative the t2 which is consistent with items added. If you are ignoring order I don't think this changes anything since i should be equal to j. But if using a compare function and not ignoring order we want the output indexes to be relative to t2 to make them able to be replayed. Only items removed are relative to t1 (since they have to be) and removed items always get replayed first in the delta objects.

[dtorres-sf]

The changes to the existing unittests are because the output is now relative to t2 instead of t1 as mentioned in the above comment.

[dtorres-sf]

This comment pretty much explains why we made this change. But it has to do with the delta modifying data in place. If we didn't make this change, the nested items would get added twice, simply because the "moved" item has the new value that includes any additions. So moved items do not need to be replayed. This just sets the place holders so all the indexes are right when we go into adding items. Then we will actually replace the None with the real value after we replay the added items.

[seperman]

That makes sense!

[dtorres-sf]

@seperman Just checking in to see if you have a moment to look at this PR.

Unrelated (sort of), appreciate all your work on maintaining - I just signed my org up for monthly donation.

[seperman]

Ah! Thanks for letting me know! I really appreciate the support and the code contributions. :) I will take a look at the PR tonight. Sep Dehpour

…

On Aug 12, 2022, at 12:50 PM, dtorres-sf ***@***.***> wrote:  @seperman Just checking in to see if you have a moment to look at this PR. Unrelated (sort of), appreciate all your work on maintaining - I just signed my org up for monthly donation. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.

[seperman]

LGTM! Great catch.

[seperman]

That makes sense!