Skip to content

[BI-641] - Validate lower and upper limits for correctness#73

Merged
ctucker3 merged 3 commits intodevelopfrom
feature/BI-641
Feb 25, 2021
Merged

[BI-641] - Validate lower and upper limits for correctness#73
ctucker3 merged 3 commits intodevelopfrom
feature/BI-641

Conversation

@ctucker3
Copy link
Contributor

@ctucker3 ctucker3 commented Feb 16, 2021

Looks like a big PR, but is mostly changes to test import files. The change to BigDecimal in the scale class required a few extra changes.

This is based off on BI-645, so that should be reviewed and merged before the review of this.

@ctucker3 ctucker3 marked this pull request as ready for review February 16, 2021 13:51
@ctucker3 ctucker3 force-pushed the feature/BI-641 branch 2 times, most recently from a5e478a to 59da9ac Compare February 17, 2021 19:40
.max(trait.getScale().getValidValueMax())
.min(trait.getScale().getValidValueMin());
.categories(trait.getScale().getCategories());
if (trait.getScale().getValidValueMax() != null) {
Copy link
Member

Choose a reason for hiding this comment

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

My suggestion would be to have the BigDecimal#setScale things done directly in the Scale class. This would mean overriding the setValidValueMax and setValidValueMin methods that are currently handled by Lombok

Copy link
Member

Choose a reason for hiding this comment

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

Then the max is less than valid value min check would be after rounding which I guess is what you'd want since that's what's being sent out.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Wouldn't that be the same as if we had kept the scale valid value max and min as an integer?

I like the idea of having it in the class though. Maybe I could add a getBrAPIValidMax and min?

Copy link
Member

Choose a reason for hiding this comment

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

Yeah, good question. Maybe I missed why that was changed to BigDecimal from Integer, @ctucker3 do you know?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Tim and I talked about this. The BigDecimal doesn't have a use since it will never be persisted. I think this card was initially created when we were going to bring all of the trait data into our schema.

I reverted all of those related changes and just implemented the min/max check.

Copy link

@DebWeigand DebWeigand left a comment

Choose a reason for hiding this comment

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

The row numbers in the error messages are off by 2

minMax_2

@ctucker3 ctucker3 force-pushed the feature/BI-641 branch 2 times, most recently from 74a3d6b to f3dbd61 Compare February 24, 2021 15:29
@ctucker3
Copy link
Contributor Author

The row numbers in the error messages are off by 2

minMax_2

I checked your file with the new changes for this card and the errors started off at row 2. Let me know if it is working for you now as well.

@ctucker3 ctucker3 merged commit cf339f6 into develop Feb 25, 2021
@ctucker3 ctucker3 deleted the feature/BI-641 branch February 25, 2021 19:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants