-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Support @JsonIgnoreProperties
to work with @JsonValue
#4070
Conversation
@@ -254,6 +258,20 @@ public void serialize(Object bean, JsonGenerator gen, SerializerProvider ctxt) t | |||
} | |||
} | |||
|
|||
private JsonSerializer<Object> _updateserWithIgnorals(JsonSerializer<Object> ser, SerializerProvider ctxt) { |
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.
This method "hypothetically" lazy initializes a serializer with @JsonIgnoreProperties
applied. Only because at line 248
ser = _findDynamicSerializer(ctxt, value.getClass());
... is called, at least for our failing-test. We need to figure out how to make the serializer final 🤔
Closed for now. I am not sure if current version takes right approach. |
I think this is a good approach in principle. There may be some edge cases -- like, should the new set of ignored properties replace what might already exist or combine it with union (I suspect union is the right thing to do). Also: not sure if you already saw it, but |
I see. My concern was with timing, because with current revision we are detecting ignorals lazily in
Will try to include tests for such edge cases. Thank you for explanation! 👍🏻 |
Accidentally closed 😅 |
@@ -126,6 +126,11 @@ protected BeanSerializerBase withProperties(BeanPropertyWriter[] properties, | |||
return new BeanSerializer(this, properties, filteredProperties); | |||
} | |||
|
|||
@Override // @since 2.16 | |||
public JsonSerializer<?> withIgnoredProperties(Set<String> toIgnore) { | |||
return new BeanSerializer(this, toIgnore, null); |
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.
My only concern here is that passing null
could remove effects of possible @JsonIncludeProperties
. But looking at BeanSerializerBase
, this information is not really retained explicitly -- but hopefully src._filteredProps
has information.
So this is why having those tests is good verification.
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.
So this is why having those tests is good verification.
True true, Makes sense 👌🏽
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.
Or maybe pass empty Set<> instead? Whichever keeps codebase consistent, that's why I somehow thought passing 'null' was the way to go
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.
Sorry, no, null
is fine (wrt empty). I was thinking out aloud that originally provided inclusion cannot be passed again (which would come from @JsonIncludeProperties
).
But let's worry about this if someone can figure out case where this is problematic.
Ok, merging to master is challenging here... but I'll get it done. One thing I realized after merging, however, is that I think that possible Another thing: I wonder if making value class Anyway I'll work on merge now, almost done. |
// [databind#3647] : Support @JsonIgnoreProperties to work with @JsonValue | ||
public class JsonValueIgnore3647Test extends BaseMapTest | ||
{ | ||
static class Foo3647 { |
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.
@JooHyukKim Making this final
will make test fail. I think this is because _valueSerializer
has then been pre-fetched.... so fix here won't work for all cases.
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.
Hmmm, I chose where fix is currently is (JsonValueSerializer.dynamicSerializer()) because of dynamically fetched types such as List in mind🤔
I think we can fix this either with reverting current change or just on top of this one. (Later in the evening, its 12nn atm)
I recall trying to apply fix at 'creatContexual' and failed because not enough information or something. You think it's possible? |
@JooHyukKim it's not either-or but both -- in static ( |
I see, I thought there may be a common and reasonable call path for both case. Thank you for helping out🙏🙏 |
Hmmh. Looking at code, I think that Let me see if I can get anything further done... |
@JooHyukKim I got it all working, I think. Including 3.0 where code had been refactored (and |
@cowtowncoder Phew, great! I saw commit messages in Quick question: Are refactoring works welcome in |
Thinking now, maybe some other that I don't know of 😆 |
Yes. On test coverage, I hope we could reduce amount of test code without reducing test coverage: since test code is code to maintain just like regular code, over time there's more baggage. So new test code needs to be meaningful and not just to increase metrics -- I am not a big fan of coverage metrics just because it sometimes leads to "silly" tests that have more code than existing in non-test code being covered. On refactoring, reducing amount of code (without adding overhead) would be welcome as well. |
relates #3647 .