applyInPlace does not work when replace root path

[ruiruige]

Expected Behavior

do replace when path is root while using applyInPlace

Actual Behavior

did nothing

input: {"throw", true}
diff: [
{
"op": "replace",
"path": "",
"value": {
"throw": false
}
}
]

applyInPlace does not replace anything. after I debug, I found InPlaceApplyProcessor does not change sourceNode when path is root:

Specifications

Library Version: 0.4.11
Language (e.g. Java 1.8, Scala, etc):Java 1.8

[holograph]

While you are correct, the Jackson API (i.e. JsonNode) doesn't actually let you accomplish what you're trying to without some changes to the zjsonpatch API as well. To clarify:

• JsonNode can be either a ValueNode (scalar) or ContainerNode (array, object)
• Containers can be edited in place with ContainerNode.removeAll, as long as the replacement is also the same type of container
• Scalar nodes cannot be edited at all (e.g. DoubleNode has a final value field)

In practice, this means applyInPlace cannot change the root node in many circumstances (replace object with scalar, replace scalar with object, replace object with array, replace array with object...). So we're left with the following options:

1. Reject patches that replace the root outright;
2. "Best faith" effort, i.e. only support replacing objects with objects and arrays with arrays;
3. Return the "replaced" root node from applyInPlace (making it effectively a limited optimization).

I don't really have a strong opinion here, since applyInPlace is an implementation feature of zjsonpatch, rather than anything specced out in the RFC. To my mind a replace on the root path should always result in a runtime exception with applyInPlace.

Thoughts @ruiruige / @vishwakarma ?

[holograph]

See #190

[vishwakarma]

Thanks @holograph

Thanks for the detailed breakdown and suggestions. I agree with your preference to reject patches that replace the root node outright when using applyInPlace. Raising a runtime exception in these cases feels like the most predictable and straightforward solution, and it keeps the behavior of applyInPlace aligned with its intended purpose.

While the other options like "best faith" efforts or returning the replaced root node offer some flexibility, they might lead to inconsistent behavior or make the method more complex than necessary. Rejecting root replacements ensures that users are explicitly handling these scenarios, which I think is the right approach