Repository navigation
Carry JSON ObjectData values in the json field and remove encoding - #577
Merged
ttypic merged 3 commits intoNov 12, 2026
Merged
Conversation
OD4c5, OD4d5, OD5a2 and OD5b3 described JSON leaf values as a `string` with `encoding: "json"`, which the service does not honour. JSON leaves are carried in the OD2g `json` field as a JSON-encoded string with both protocols, so encode and decode them there. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
With JSON leaf values carried in the OD2g `json` field, nothing sets `ObjectData.encoding` any more, so delete OD2b and OD4b, drop the field from the IDL, and stop referring to it from RSO9c1. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
VeskeR
approved these changes
Nov 12, 2026
VeskeR
left a comment
Contributor
There was a problem hiding this comment.
LGTM, comment about bumping spec version
| - `(OD2)` The attributes available in an `ObjectData` are listed below. Of the value fields - `boolean`, `bytes`, `number`, `string` and `json` - at most one must be set at a time: | ||
| - `(OD2a)` `objectId` string - a reference to another object | ||
| - `(OD2b)` `encoding` string - may be set by the client library to indicate that value in `string` field have an encoding | ||
| - `(OD2b)` This clause has been deleted as of specification version 6.4.0. |
Contributor
There was a problem hiding this comment.
Feel free to bump spec version to 6.4.0 as well in build/data/versions.yaml - this will go out with LO REST APO spec changes
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This branch was successfully deployed
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
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.
Split out of #569 following review, so that the general
ObjectDatachange is findable on its own rather than hidden inside the REST UTS PR.Changes
JSON leaves use the
jsonfield. OD4c5, OD4d5, OD5a2 and OD5b3 described JSON leaf values as astringwithencoding: "json", which the service does not honour. JSON leaves are now encoded into and decoded from the OD2gjsonfield as a JSON-encoded string, with both the JSON and MessagePack protocols.ObjectData.encodingremoved. Nothing sets it any more, so OD2b and OD4b are marked deleted, the field is dropped from the IDL, and RSO9c1 no longer refers to it.Spec version bumped to 6.4.0 in
build/data/versions.yaml, matching the version in the deletion notices.🤖 Generated with Claude Code