-
Notifications
You must be signed in to change notification settings - Fork 55
Distinguish missing vs null in var resolution (use default only when missing)
#58
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
Conversation
fix: distinguish missing vs null in var resolution using MISSING
…i-config [LT-1633] update Gradle build and CircleCI config
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please remove
jamsesso
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm happy with the code fixes but I'm not onboard with the CI changes. Those should be a separate PR. Because the two are mixed in here, I'll have to decline.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Remove this change
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Remove this change
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm fine upgrading Gradle, but can this be done in another PR?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same comment as before - bundling two different changes in a PR (missing + gradle changes) isn't ideal. I don't want to discuss two changes in a single PR. the code for MISSING seems fine and can be deployed, but this is something I'd like to think about more.
|
Sorry about that, that was not my intention. |
This fixes
varresolution so a default is applied only when the path is missing, not when the value is explicitlynull.Why
Per the JsonLogic docs, the second
varargument is a default “for values that might be missing.” Treatingnullas missing deviates from that intent and leads to surprising results.What changed
MISSINGsentinel to track “not found” during path traversal.containsKeyto differentiate an absent key from a present key withnull.MISSINGfor out-of-bounds indices.evaluate(JsonLogicVariable, …)applies the default only when the traversal yieldsMISSING; explicitnullis returned asnull.Examples
{"var": ["user.age", 42]}with{"user":{"age": null}}→ null (no default){"var": ["items.2", "missing"]}with{"items":[10,20]}→ "missing"{"var": ""}returns the entire data object (same instance)Tests
Added coverage to
VariableTests:nullreturnsnull(no default).nullor non-traversable types returnnull.varkey returns the original data object.Compatibility
Behavior change for callers who relied on “default-for-null.” This aligns with the JsonLogic spec and other interpreters.