Keep explicitly null to-one relationships as present-with-null - #50
Merged
Conversation
The JSON:API serializer dropped a to-one relationship serialized with "data": null from the parsed resource entirely, so strict reads raised Booqable::MissingAttribute — but a null relationship is present-with-null (the order line HAS no item), exactly like a null attribute, which the StrictAttributes contract says reads as nil. Keep the key, set it to nil. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
booqbruno
self-requested a review
July 16, 2026 12:13
booqbruno
approved these changes
Jul 16, 2026
Merged
shime
added a commit
that referenced
this pull request
Jul 16, 2026
Included since 2.0.0: - Add the `app_issues` resource (CRUD for `App::Issue`) (#51) - Fix: a to-one relationship serialized with `"data": null` (e.g. a charge line's `item`, or an included `barcode` on a product without one) now reads as nil, matching the present-with-null attribute semantics — instead of the parser dropping the key and the read raising `Booqable::MissingAttribute` (#50) Originally opened as 2.0.1; renamed to 2.1.0 because #51 adds a resource (a feature, per the 1.1.0/1.2.0 precedent). The branch name still says `release/2.0.1` — cosmetic only, the tag comes from `version.rb`. Unblocks [logistics#26](booqable/logistics#26), which is temporarily git-pinned to the #50 SHA — once this ships, the pin swaps back to the published gem. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
booqable 2.0's strict attribute reads treat "present with a null value" as nil and only raise
Booqable::MissingAttributefor keys absent from the payload. But the JSON:API serializer drops a to-one relationship serialized with"data": nullfrom the parsed resource entirely, so it reads as absent and raises.That breaks real, everyday payloads in the apps — found while merging booqable 2.0 into logistics' weights PR (logistics#26):
"item": {"data": null}→line.itemraises instead of returning nil"barcode": {"data": null}→item.barcoderaisesA null relationship is present-with-null — the line has no item — exactly like a null attribute, so the parser now keeps the key and sets it to nil. To-many relationships are unaffected (
datais always an array), and absent relationships still raise as designed.🤖 Generated with Claude Code