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

[ question / suggestion ] configure implicit conversions #31

Open
mraasvel opened this issue Sep 11, 2024 · 2 comments
Open

[ question / suggestion ] configure implicit conversions #31

mraasvel opened this issue Sep 11, 2024 · 2 comments

Comments

@mraasvel
Copy link

Hello,

I was wondering about your opinion on possible adding some kind of configuration option to disallow implicit conversions.

Explanation

Given a JSON like this, where the value of key is a floating point number:

{
  "key": 1.100000000000000000000000000001
}

But we explicitly expect a string, since implicit conversion can cause rounding issues

message Example {
  string key = 1;
}

Expected behavior:

Parsing fails with an error since the JSON type does not match the expected type

Actual behavior:

Parser implicitly parses the value as a float and converts the result to a String, resulting in unwanted rounding:

quantity: "1.1"

This is because all of the Jackson JsonParser implementations do implicit conversions if asked for that particular value: https://groups.google.com/g/jackson-user/c/_VNLt7LYupI

@chokoswitch
Copy link
Contributor

Hi @mraasvel - sorry for the really slow response. I added a test in #32 to confirm our behavior currently matches upstream. This repo is meant to be just a performance optimization of the upstream marshaller and we don't want to add features independently - while it's possible if there is a Jackson-specific mechanism, as you found it seems Jackson also doesn't allow configuring this at the JsonParser level. So my recommendation is if this is important, to file an issue upstream to see if they would add an option to disable implicit conversion. If they do, we'll add it here. How does that sound?

@chokoswitch
Copy link
Contributor

Actually, I realized your issue may be less about preventing the implicit conversion and more about making sure the result isn't rounded. In #33, I updated to use your exact input and verified it behaves the same as upstream by parsing an unrounded value. Can you compare your code with the test case to see what could be causing you to see a different result?

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

No branches or pull requests

2 participants