Skip to content
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

Add an extension to have a relaxed interpretation of the RFC-6902 #174

Open
satabin opened this issue Jul 9, 2020 · 1 comment
Open

Comments

@satabin
Copy link
Member

satabin commented Jul 9, 2020

For some use cases, pre-condition for a given operation might be relaxed (e.g. the pre-condition that a deleted element has to exist).

An optional strict boolean field can be added to operations where it makes sense so that the operation doesn't fail if the pre-condition doesn't hold, and the operation is simply ignored.

This is not part of the standard, and the default behavior should be unchanged.

@davesmith00047
Copy link

I came here to raise a similar issue.

At the moment the diff is correct, but correct isn't always helpful, and the signal to noise ratio of the diff could be improved by adding the ability to set some options. The three low hanging options I'd personally like to be able to specify are:

  1. A missing key, and a key set to null are considered equal. I can get my JSON lib to do this for me in a pre-processing step, but it would be nice to just tell the differ to deal with it.
  2. Object keys are sorted, so that order doesn't matter. This one may already work since I seem to recall it's part of the spec, I haven't checked.
  3. Similarly, array order (globally is fine, unless you want to allow Pact style path based matching rules) can be ignored, i.e. as long as the array contains all the same things and is the same length, it's ok.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants