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

IGNITE-23172 Sql. Lack of bounds validation in CAST(1 as DECIMAL(MAX_PREC, MAX_SCALE)) #4566

Merged
merged 7 commits into from
Oct 16, 2024

Conversation

korlov42
Copy link
Contributor

https://issues.apache.org/jira/browse/IGNITE-23172

This patch changes the rules for type derivation of dynamic param for BigDecimal:

  • by default type is DECIMAL(28, 6)
  • there is an ability to specify precise type by wrapping dye param placeholder with CAST operator

Thank you for submitting the pull request.

To streamline the review process of the patch and ensure better code quality
we ask both an author and a reviewer to verify the following:

The Review Checklist

  • Formal criteria: TC status, codestyle, mandatory documentation. Also make sure to complete the following:
    - There is a single JIRA ticket related to the pull request.
    - The web-link to the pull request is attached to the JIRA ticket.
    - The JIRA ticket has the Patch Available state.
    - The description of the JIRA ticket explains WHAT was made, WHY and HOW.
    - The pull request title is treated as the final commit message. The following pattern must be used: IGNITE-XXXX Change summary where XXXX - number of JIRA issue.
  • Design: new code conforms with the design principles of the components it is added to.
  • Patch quality: patch cannot be split into smaller pieces, its size must be reasonable.
  • Code quality: code is clean and readable, necessary developer documentation is added if needed.
  • Tests code quality: test set covers positive/negative scenarios, happy/edge cases. Tests are effective in terms of execution time and resources.

Notes

- add test for precision and scale less than default one
@@ -51,7 +50,7 @@
public class NumericCaseTypeCoercionTest extends BaseTypeCoercionTest {
private static final IgniteSchema SCHEMA = createSchemaWithTwoColumnTable(NativeTypes.STRING, NativeTypes.STRING);

private static final NativeType DECIMAL_MAX_PREC = NativeTypes.decimalOf(MAX_DECIMAL_PRECISION, 0);
private static final NativeType DECIMAL_DYN_PARAM_DEFAULT = NativeTypes.decimalOf(28, 6);
Copy link
Contributor

@xtern xtern Oct 16, 2024

Choose a reason for hiding this comment

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

why not use DECIMAL_DYNAMIC_PARAM_PRECISION and DECIMAL_DYNAMIC_PARAM_SCALE constants?
I mean

NativeTypes.decimalOf(DECIMAL_DYNAMIC_PARAM_PRECISION, DECIMAL_DYNAMIC_PARAM_SCALE);

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 catch, fixed

@@ -81,9 +82,12 @@ void testMetadataTypesForDynamicParameters(ColumnType type) {
// TODO https://issues.apache.org/jira/browse/IGNITE-19162 Ignite SQL doesn't support precision more than 3 for temporal types.
if (type == ColumnType.TIME || type == ColumnType.TIMESTAMP || type == ColumnType.DATETIME) {
param = SqlTestUtils.generateValueByType(type, 3, -1);
} else if (type == ColumnType.DECIMAL) { // by default derived type of parameter of type BigDecimal is DECIMAL(28, 6)
param = SqlTestUtils.generateValueByType(type, 28, 6);
Copy link
Contributor

Choose a reason for hiding this comment

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

why not use constants?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

fixed

@korlov42 korlov42 merged commit 55a896a into apache:main Oct 16, 2024
1 check passed
@korlov42 korlov42 deleted the ignite-23172 branch October 16, 2024 14:53
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.

3 participants