Skip to content

OBPIH-6965 add data binding support for java.time classes#5023

Merged
ewaterman merged 6 commits intodevelopfrom
ft/OBPIH-6965-support-binding-java-time-types
Feb 12, 2025
Merged

OBPIH-6965 add data binding support for java.time classes#5023
ewaterman merged 6 commits intodevelopfrom
ft/OBPIH-6965-support-binding-java-time-types

Conversation

@ewaterman
Copy link
Member

✨ Description of Change

Link to GitHub issue or Jira ticket: https://pihemr.atlassian.net/browse/OBPIH-6965

Description:

Add support for java.time.Instant and java.time.LocalDate data binding. With this change we can now use those data types in our Domain classes and DTO/Command objects. This is important because java.util.Date is functionally deprecated as of Java 8, so going forward we should stop using it if possible.

See my other PR for an example implementation that uses this change: #5022

This is based off the discovery work I did on java.time in OBPIH-6916. I encourage you to read that if you want some background information on this change.

@ewaterman ewaterman self-assigned this Jan 31, 2025
@github-actions github-actions bot added type: feature A new piece of functionality for the app domain: backend Changes or discussions relating to the backend server flag: config change Hilights a pull request that contains a change to the app config labels Jan 31, 2025
@ewaterman ewaterman changed the title add data binding support for java.time classes OBPIH-6965 add data binding support for java.time classes Jan 31, 2025

private Date parseDateShipped(String date) {
return date ? Constants.DELIVERY_DATE_FORMATTER.parse(date) : null
return DateUtil.asDate(date, Constants.DELIVERY_DATE_FORMATTER)
Copy link
Member Author

Choose a reason for hiding this comment

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

This is a fix for https://pihemr.atlassian.net/browse/OBS-1831. I wanted something real to test my changes against so figured I'd fix the issue while I was at it.

@codecov
Copy link

codecov bot commented Jan 31, 2025

Codecov Report

Attention: Patch coverage is 53.73134% with 31 lines in your changes missing coverage. Please review.

Project coverage is 7.84%. Comparing base (55ecc59) to head (7e6e6f4).
Report is 211 commits behind head on develop.

Files with missing lines Patch % Lines
grails-app/utils/org/pih/warehouse/DateUtil.groovy 52.63% 11 Missing and 7 partials ⚠️
.../warehouse/databinding/StringValueConverter.groovy 25.00% 6 Missing ⚠️
...ih/warehouse/api/StockMovementApiController.groovy 0.00% 2 Missing ⚠️
...warehouse/databinding/InstantValueConverter.groovy 66.66% 1 Missing and 1 partial ⚠️
...rehouse/databinding/LocalDateValueConverter.groovy 60.00% 1 Missing and 1 partial ⚠️
.../warehouse/databinding/DataBindingConstants.groovy 80.00% 1 Missing ⚠️
Additional details and impacted files
@@             Coverage Diff              @@
##             develop   #5023      +/-   ##
============================================
+ Coverage       7.75%   7.84%   +0.08%     
- Complexity       860     876      +16     
============================================
  Files            613     624      +11     
  Lines          42622   42815     +193     
  Branches       10350   10375      +25     
============================================
+ Hits            3306    3357      +51     
- Misses         38822   38955     +133     
- Partials         494     503       +9     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

// TODO: Don't add more dates here! We should refactor all usages of these constants to instead use the
// DateTimeFormatter constants in DateUtil. The backend should always return dates in the same format so that
// the frontend can easily parse response objects. Let the frontend decide what the display format of each
// individual field should be.
Copy link
Member Author

@ewaterman ewaterman Jan 31, 2025

Choose a reason for hiding this comment

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

my idea here is that we should always use the same format when returning dates to the frontend, and then let the frontend format the dates for display.

As such, I hope we can eventually remove most of these from the backend and simply call toString() on the Instant/LocalDate datatypes in the toJson() method of our Domains/DTOs/CommandObjects.

As for how to parse date on the frontend, Alan did a discovery that is quite relevant

@ewaterman ewaterman merged commit 6bb60bc into develop Feb 12, 2025
9 checks passed
@ewaterman ewaterman deleted the ft/OBPIH-6965-support-binding-java-time-types branch February 12, 2025 15:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

domain: backend Changes or discussions relating to the backend server flag: config change Hilights a pull request that contains a change to the app config type: feature A new piece of functionality for the app

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant