Skip to content
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

Fix FasterXML#3013: Implement int-to-string coercion config #3608

Merged

Conversation

Tomasito665
Copy link
Contributor

Description

This pull request implements configurable integer to string coercion.

Issue

#3013

@cowtowncoder
Copy link
Member

Note to self: we do have CLA for this.

@@ -61,6 +62,15 @@ public String deserialize(JsonParser p, DeserializationContext ctxt) throws IOEx
if (t == JsonToken.START_OBJECT) {
return ctxt.extractScalarFromObject(p, this, _valueClass);
}
if (t == JsonToken.VALUE_NUMBER_INT) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could this be simplified by calling _parseString(...) and removing handling of START_OBJECT, VALUE_EMBEDDED_OBJECT (that are handled there)?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good one! Yes, it can. I've rewritten this method in terms of _parseString(...), leaving only the START_ARRAY case in the original method and the VALUE_STRING case at the very top as an optimization — I assume it is the most common case, so I figured it would make sense to keep that there even if it is already handled in _parseString(...). If you think this is a premature optimization, let me know and I'll remove it :-)

@cowtowncoder
Copy link
Member

Looks good; I have one potential suggestion here, but happy to merge otherwise.

@Tomasito665
Copy link
Contributor Author

I have implemented your suggestion. For some reason, the ObjectReaderValueOfWithValueTypeTest test case fails in CI for Java 8. The tests pass on my machine, both with Java 8 and 17. Any idea what's happening here?

@cowtowncoder
Copy link
Member

@Tomasito665 That is odd and I doubt it has anything to do with your changes. I actually ended up removing that test case since I do not think it adds any value (uses Mock objects to verify something that ... does not seem valuable).

I'll see if I can get PR itself now reviewed.

@cowtowncoder
Copy link
Member

Ok, this looks good. I will need to go over it one more time, merge hopefully tomorrow, possibly making minor tweaks.
I think we need to add an overload for old version of _parseString() just because something in other modules might be calling it -- need to default NullValueProvider to, NullsConstantProvider.nuller(). If you get to do it first that'd be great; if not I'll add it after merging.

@cowtowncoder cowtowncoder merged commit 53f5dda into FasterXML:2.14 Oct 2, 2022
@cowtowncoder
Copy link
Member

@Tomasito665 I just merged this, so if you want to do another PR for coercion from Float etc, should be possible.

Thank you again for contributing this!

@Tomasito665
Copy link
Contributor Author

Wonderful, thanks for merging, @cowtowncoder. I wanted to add the method overload for _parseString() without the null provider, as you suggested, but you were faster :-) I'll file a new PR for the pending types in the coming days.

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