exceptionfactory opened a new pull request #5210:
URL: https://github.com/apache/nifi/pull/5210
#### Description of PR
NIFI-8768 Adds `DataTypeUtils.toLocalDate()` and updates
`DataTypeUtils.convertType()` to use a new `convertTypeToDate()` method for
converting input values to `java.sql.Date` when processing fields of
`RecordFieldType.DATE`. The purpose of these changes is to handle
year-month-day values using local system default time zone settings instead of
performing implicit conversion in some scenarios. These changes address latent
issues when converting strings to `java.sql.Date` objects on systems with a
time zone other than Universal Coordinated Time.
Processors such as `PutKudu`, `PutDatabaseRecord`, and
`PutElasticsearchHttpRecord` leverage Record Readers to convert information
from original formats to records that NiFi uses for persisting to the
destination system. For example, when configured with a `JsonTreeReader`, these
processors can take a year-month-day string such as `2000-01-01` and store it
using the logical `DATE` type of the destination system. When running on
systems with a time zone other than UTC, these processors could result in
storing a logical year-month-day of `1999-12-31` when receiving a record with a
string field value of `2000-01-01`. Pull Request #4781 for NIFI-8023 addressed
this problem for `PutDatabaseRecord` using a workaround conversion method
`DataTypeUtils.convertDateToLocalTZ()`. The issue was still present in
`PutKudu` due to the behavior of Record Readers such as `JsonTreeReader`
leveraging the String to `java.sql.Date` conversion methods in `DataTypeUtils`.
The combination of an implicit default Time Zone of GMT in
`DataTypeUtils.getDateFormat()` and the absence of a declared time zone in
year-month-day strings such as `2000-01-01` results in unexpected date changes
when running in time zones other than UTC. This Pull Request addresses the
problem by handling `RecordFieldType.DATE` and `java.sql.Types.DATE` according
to the system default time zone, as implied by the use of `java.time.LocalDate`
for parsing and conversion to `java.sql.Date`. This approach removes the need
for the custom `DataTypeUtils.convertDateToLocalTZ()` method in
`PutDatabaseRecord`. This change applies only to `DATE` fields does not
involve `TIME` or `TIMESTAMP` fields.
Both `java.time.LocalDate` and `java.sql.Date` represent a year-month-day
combination without reference to a time zone, thus converting to UTC can change
the day by shifting the number of hours forward or backward from the original
year-month-day in the local system time zone. This Pull Request includes
several additional unit test methods for both `DataTypeUtils` and referencing
processors to describe and confirm expected behavior. Introduction of
`DataTypeUtils.toLocalDate()` and `DataTypeUtils.convertTypeToDate()` provide
methods to handle existing classes that expect `java.sql.Date` while also
supporting classes that can leverage the newer `java.time.LocalDate`.
In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:
### For all changes:
- [X] Is there a JIRA ticket associated with this PR? Is it referenced
in the commit message?
- [X] Does your PR title start with **NIFI-XXXX** where XXXX is the JIRA
number you are trying to resolve? Pay particular attention to the hyphen "-"
character.
- [X] Has your PR been rebased against the latest commit within the target
branch (typically `main`)?
- [X] Is your initial contribution a single, squashed commit? _Additional
commits in response to PR reviewer feedback should be made on this branch and
pushed to allow change tracking. Do not `squash` or use `--force` when pushing
to allow for clean monitoring of changes._
### For code changes:
- [X] Have you ensured that the full suite of tests is executed via `mvn
-Pcontrib-check clean install` at the root `nifi` folder?
- [X] Have you written or updated unit tests to verify your changes?
- [X] Have you verified that the full build is successful on JDK 8?
- [X] Have you verified that the full build is successful on JDK 11?
- [ ] If adding new dependencies to the code, are these dependencies
licensed in a way that is compatible for inclusion under [ASF
2.0](http://www.apache.org/legal/resolved.html#category-a)?
- [ ] If applicable, have you updated the `LICENSE` file, including the main
`LICENSE` file under `nifi-assembly`?
- [ ] If applicable, have you updated the `NOTICE` file, including the main
`NOTICE` file found under `nifi-assembly`?
- [ ] If adding new Properties, have you added `.displayName` in addition to
.name (programmatic access) for each of the new properties?
### For documentation related changes:
- [ ] Have you ensured that format looks appropriate for the output in which
it is rendered?
### Note:
Please ensure that once the PR is submitted, you check GitHub Actions CI for
build issues and submit an update to your PR as soon as possible.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
