-
Notifications
You must be signed in to change notification settings - Fork 71
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
New Rule: date conversions with format model #40
Comments
from SonarQube "TO_NUMBER" should be used with a format model The TO_NUMBER function is converting the value of BINARY_FLOAT, BINARY_DOUBLE, CHAR, VARCHAR2, NCHAR, or NVARCHAR2 datatype to a value of NUMBER datatype. Without providing the format of the input, TO_NUMBER will consider the provided value is compliant with the default format. Relying on a default configuration is a source of error because it creates a dependency between the code and the configuration of the ORACLE server where this code is deployed. The behaviour of the TO_NUMBER function will certainly not be the expected one if the configuration of the ORACLE server is changing. Noncompliant Code Example The following code with return 0 on an ORACLE server running with its default US configuration with p_string = "2,540"
Compliant Solution The following code with return 1 on an ORACLE server running with its default FR configuration with p_string = "2,540" because the comma will be interpreted as decimal separator instead of thousand separator.
|
from SonarQube: "TO_DATE" and "TO_TIMESTAMP" should be used with a datetime format model The TO_DATE and TO_TIMESTAMP functions are converting char of CHAR, VARCHAR2, NCHAR, or NVARCHAR2 datatype to respectively a value of DATE or TIMESTAMP datatype. Without providing the format of the input char, TO_DATE will consider the provided char is compliant with the default date format. Relying on a default configuration is a source of error because it creates a dependency between the code and the configuration of the ORACLE server where this code is deployed. According to the Oracle's documentation "the default date format is determined implicitly by the NLS_TERRITORY initialization parameter or can be set explicitly by the NLS_DATE_FORMAT parameter.". It means the behaviour of the TO_DATE function will certainly not be the expected one if the configuration of the ORACLE server is changing. Noncompliant Code Example
Compliant Solution
|
I agree for |
I would extend the rule towards: |
Good idea regarding the
I suggest to handle this in and additional rule. I'd keep the scope of this rule to all conversions which rely on a database (NLS) settings. Based on that, it is necessary to define a format also for
Summary: I suggest to create based on this issue the following two rules:
|
CAST has it also... |
Thanks @rogertroller , I've added it in the comment above. |
One problem concerning TO_NUMBER is that there is no way to specify with a format model the same functionality as if not specifying format model. See details in section "Usecase" here: https://community.oracle.com/tech/apps-infra/discussion/4404178/parameters-should-accept-keyword-default-to-indicate-we-want-same-behaviour-as-if-parameter-was-not For the datetime TO_* functions, not specifying format model means using the format model from NLS settings (as well as utilizing the other various NLS parameters to decide how to interpret the elements of the format model.) For TO_NUMBER, not specifying format model means a default of "any number of digits and a possible decimal separator", where the decimal separator is dependent on session NLS setting (and you can't use the third parameter of TO_NUMBER to specify NLS_NUMERIC_CHARACTERS without specifying a format model.) If we say to always use format model for TO_NUMBER, that requires using a format model with many many 9's in it to emulate the same functionality as we get by using TO_NUMBER without format model. I think I am going for multiple rules here:
(I'm adding a section under Language Usage called Function Usage - there's potential for more rules there ;-)) |
** Language Usage / General** or Language Usage / Variables & Types / General
Always use a format model in the functions TO_DATE and TO_TIMESTAMP
The text was updated successfully, but these errors were encountered: