resolve null d case management

[eliSkylight]

Notes

This PR adds a fallback logic to the sp_investigation_event stored procedure to copy MasterETL mapping of codes in the NBS_SRTE.CODE_VALUE_GENERAL table. This change removes the current value of NULL in the INIT_FUP_INITIAL_FOLL_UP in RDB_MODERN.D_CASE_MANAGEMENT for unmapped codes.

This does not effect codes that are already mapped successfully.

JIRA

Jira Ticket: APP-295

Checklist

• PR focuses on a single story.
• New unit tests added and ensured they pass.
• Service has been tested in local and it works as expected.
• Documentation has been updated for this code change (if needed).
• Code follows the Java Coding Conventions (https://www.oracle.com/java/technologies/javase/codeconventions-programmingpractices.html).

Types of changes

What types of changes does this PR introduces?

• Bugfix
• New feature
• Breaking change

Testing

• Does this PR has >90% code coverage?
• Is the screenshot attached for code coverage?
• Does the gradle build pass in your local?
• Is the gradle build logs attached?

Result Screenshot

Gradle build logs

Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Delta compression using up to 10 threads
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 333 bytes | 333.00 KiB/s, done.
Total 3 (delta 2), reused 0 (delta 0), pack-reused 0
remote: Resolving deltas: 100% (2/2), completed with 2 local objects.
To github.com:CDCgov/NEDSS-DataReporting.git
   26e68e45..26817f7f  err/app-295/resolve-null-d_case_management -> err/app-295/resolve-null-d_case_management
ereyes@ip-192-168-50-168 NEDSS-DataReporting % gradle build
Starting a Gradle Daemon (subsequent builds will be faster)
OpenJDK 64-Bit Server VM warning: Sharing is only supported for boot loader classes because bootstrap classpath has been appended

> Task :investigation-service:compileTestJava
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
OpenJDK 64-Bit Server VM warning: Sharing is only supported for boot loader classes because bootstrap classpath has been appended
OpenJDK 64-Bit Server VM warning: Sharing is only supported for boot loader classes because bootstrap classpath has been appended
OpenJDK 64-Bit Server VM warning: Sharing is only supported for boot loader classes because bootstrap classpath has been appended
OpenJDK 64-Bit Server VM warning: Sharing is only supported for boot loader classes because bootstrap classpath has been appended
OpenJDK 64-Bit Server VM warning: Sharing is only supported for boot loader classes because bootstrap classpath has been appended
OpenJDK 64-Bit Server VM warning: Sharing is only supported for boot loader classes because bootstrap classpath has been appended
OpenJDK 64-Bit Server VM warning: Sharing is only supported for boot loader classes because bootstrap classpath has been appended

[Incubating] Problems report is available at: file:///Volumes/skylight-dev/development/nbs7/NEDSS-DataReporting/build/reports/problems/problems-report.html

Deprecated Gradle features were used in this build, making it incompatible with Gradle 10.

You can use '--warning-mode all' to show the individual deprecation warnings and determine if they come from your own scripts or plugins.

For more on this, please refer to https://docs.gradle.org/9.2.1/userguide/command_line_interface.html#sec:command_line_warnings in the Gradle documentation.

BUILD SUCCESSFUL in 1m 53s
70 actionable tasks: 70 executed
Consider enabling configuration cache to speed up this build: https://docs.gradle.org/9.2.1/userguide/configuration_cache_enabling.html```

[ericbuckley]

What do you think about changing the function, fn_get_value_by_cvg, instead? That way, it's easy to apply this "default" logic to other use cases.

[eliSkylight]

What do you think about changing the function, fn_get_value_by_cvg, instead? That way, it's easy to apply this "default" logic to other use cases.

Only worry I have there is if that causes issues with other stored procedures that call that function. And what would it look like to test and confirm that it wouldn't cause issues.

[ericbuckley]

What do you think about changing the function, fn_get_value_by_cvg, instead? That way, it's easy to apply this "default" logic to other use cases.

Only worry I have there is if that causes issues with other stored procedures that call that function. And what would it look like to test and confirm that it wouldn't cause issues.

@eliSkylight this is a good point, if we change the functionality at the function level, we'll likely need to run data compare again to make sure there aren't any regressions. Your solution is probably the best for now. If we see a pattern develop after a couple of these NULL fixes, maybe we should revisit our strategy.

[hawley-skylight]

I agree with the suggestion that fn_get_value_by_cvg is the better place to put this. However, I am fine with revisiting this later.