Fix to "BigDecimal has mismatching scale value for given Decimal schema"

[patelliandrea]

Fix to issue #44 as suggested in the comments

[ConfluentJenkins]

Can one of the admins verify this patch?

[ghost]

Hey @patelliandrea,
thank you for your Pull Request.

It looks like you haven't signed our Contributor License Agreement, yet.

The purpose of a CLA is to ensure that the guardian of a project's outputs has the necessary ownership or grants of rights over all contributions to allow them to distribute under the chosen licence.
Wikipedia

You can read and sign our full Contributor License Agreement here.

Once you've signed reply with [clabot:check] to prove it.

Appreciation of efforts,

clabot

[ewencp]

ok to test

[ewencp]

Can we test this change in JdbcSourceTaskConversionTest where we test a bunch of other conversions?

[clumsy]

Looks like we only need scale when the value is not NULL.
I suggest placing this in the corresponding else clause.

[patelliandrea]

Hi, I've removed the double ;
The function passed all the tests in the JdbcSourceTaskConversionTest class

[patelliandrea]

@ConfluentCLABot [clabot:check]

[ghost]

@confluentinc It looks like @patelliandrea just signed our Contributor License Agreement. 👍

Always at your service,

clabot

[ewencp]

@patelliandrea I was curious about additional tests that actually trigger the need for this. I know we validate the scale in the logical type conversion which is why this is needed, but I'm not sure when it is occurring. setScale can throw an ArithmeticException if the scale is being reduced and the conversion would require rounding, and that isn't handled here. I would assume no database should be returning data with higher precision than requested, but since I don't know why/how this is happening in the first place I think it's probably better not to make an assumption like that.

[patelliandrea]

@ewencp I've actually encountered the ArithmeticException because the conversion needed rounding so right now I'm using setScale with an hardcoded rounding mode, I'm working in order to make the rounding mode configurable.

[clumsy]

Why do you need to get the value twice? I believe you already have it in bigDecimalValue. Which is why I suggest:

colValue = bigDecimalValue.setScale(scale);

[cla-assistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}