Skip to content

Conversation

@wsorenson
Copy link

Allow @JsonInclude annotation on @StoredAsJson fields to control serialization inclusion for the nested JSON content only.

This enables use cases like excluding empty collections from nested JSON while preserving the default ALWAYS behavior for top-level fields (required for proper DB column binding).

The implementation creates a cached mapper copy with the standard JacksonAnnotationIntrospector (removing RosettaAnnotationIntrospector's ALWAYS override) when @JsonInclude is present on the field.

Usage:
@StoredAsJson
@JsonInclude(Include.NON_EMPTY)
InnerBean inner; // Empty collections excluded from nested JSON

Allow @JsonInclude annotation on @StoredAsJson fields to control
serialization inclusion for the nested JSON content only.

This enables use cases like excluding empty collections from nested
JSON while preserving the default ALWAYS behavior for top-level
fields (required for proper DB column binding).

The implementation creates a cached mapper copy with the standard
JacksonAnnotationIntrospector (removing RosettaAnnotationIntrospector's
ALWAYS override) when @JsonInclude is present on the field.

Usage:
  @StoredAsJson
  @JsonInclude(Include.NON_EMPTY)
  InnerBean inner;  // Empty collections excluded from nested JSON

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
@jhaber
Copy link
Member

jhaber commented Jan 31, 2026

Allow @JsonInclude annotation on @StoredAsJson fields to control serialization inclusion for the nested JSON content only.

Do you have more info on why this matters? Is it just an optimization of storage space? Normally I would expect that as long as read(write(x)) == x it doesn't really matter what happens in the middle

@wsorenson
Copy link
Author

the primary reason is readability, very annoying to scan db rows in the cli with all the excess keys, but you could also make a case for storage size, performance benefits, especially when dealing with large, sparse json objects.

i'm assuming these are the reasons these annotations exist to begin with, i won't even argue about whether this should be the default for json objects stored in mysql (although I would) but it seems like if you explicitly want this to work for a specific field, it should work, which it doesn't currently.

@jhaber
Copy link
Member

jhaber commented Feb 2, 2026

The idea definitely makes sense, but I'm skeptical of the implementation on this branch. I think what we're looking for is to have the stored-as-json serializers maintain a single extra ObjectMapper which doesn't use the rosetta annotation introspector, that way it doesn't pick up the ALWAYS include override. I tried this out over here:
master...jh/stored-as-json-inclusion

We'll need to do more extensive internal testing as people frequently rely on very subtle Jackson/Rosetta interactions (often unintentionally)

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants