-
Notifications
You must be signed in to change notification settings - Fork 148
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
New flags introduces non compatible changes to JsonDiff.asJson #61
Comments
Agree wholeheartedly. I was thinking along those lines when I saw the
merge, but you managed to articulate this much more clearly than I would 👍
…On Thu, 28 Dec 2017 at 12:42 Peter Bäckman ***@***.***> wrote:
Hi this is related to Issue #51
<#51>. As of Issue
#58 <#58> a new
optional feature was introduced adding a new flag:
OMIT_ORIGINAL_VALUE_ON_REPLACE. This made the API break for public static
JsonNode asJson(final JsonNode source, final JsonNode target,
EnumSet<DiffFlags> flags) since I get different output with unchanged
input. I think this method should be treated with the same vigilance as the
method without flags. Now I must go through all changes to see if the logic
has changed between versions and add corresponding flags to the call to the
method.
I propose that flags in the future are added with relation to the default
behaviour of the library. For #58
<#58> it should have
been ADD_ORIGINAL_VALUE_ON_REPLACE instead of OMIT_. I think it is much
easier to understand. In this way both public methods can be kept
compatible when new flags are added.
I hope you can see the benefit of this change of principles?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#61>, or mute the
thread
<https://github.com/notifications/unsubscribe-auth/ABEC4Nf6K01lNPyemHz51U2S164tFmgYks5tE3CBgaJpZM4RONeC>
.
|
I vote for the following approach:
Edit: Also, maybe create a new Enum called JsonPatchFeatures and JsonDiffFeatures with the suggested names. |
@PeterBackman, could you please provide a snippet of the issue? I will take some time later to fix it |
Sample code used in both versions: EnumSet<DiffFlags> patchFlags = EnumSet.of(
DiffFlags.OMIT_VALUE_ON_REMOVE,
DiffFlags.OMIT_MOVE_OPERATION,
DiffFlags.OMIT_COPY_OPERATION);
JsonNode result = JsonDiff.asJson(source, target, patchFlags); JsonPatch 0.3.5: JsonPatch 0.4.0: |
Let me ask: Since compatibility is already "broke", should I rename the OMIT_. to ADD_. and change the behavior of the flag? Or like I said earlier, deprecate the method and follow with my approach? |
I looked at the commits and saw that the flag was introduced in 0.3.10 which is quite recent so it makes sense to change that flag. From my perspective the patch looks good. Long term I think a rewrite of the interface is good. Using the methods with the flags parameter are non-intuitive. Perhaps something for next year 😃 |
Thanks @PeterBackman @LouizFC |
Hi this is related to Issue #51. As of Issue #58 a new optional feature was introduced adding a new flag: OMIT_ORIGINAL_VALUE_ON_REPLACE. This made the API break for
public static JsonNode asJson(final JsonNode source, final JsonNode target, EnumSet<DiffFlags> flags)
since I get different output with unchanged input. I think this method should be treated with the same vigilance as the method without flags. Now I must go through all changes to see if the logic has changed between versions and add corresponding flags to the call to the method.I propose that flags in the future are added with relation to the default behaviour of the library. For #58 it should have been ADD_ORIGINAL_VALUE_ON_REPLACE instead of OMIT_. I think it is much easier to understand. In this way both public methods can be kept compatible when new flags are added.
I hope you can see the benefit of this change of principles?
The text was updated successfully, but these errors were encountered: