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

[IDEA] Make "database" the default for configurationmap.location #5746

Open
joshmc82 opened this issue Apr 4, 2023 · 1 comment
Open

[IDEA] Make "database" the default for configurationmap.location #5746

joshmc82 opened this issue Apr 4, 2023 · 1 comment
Labels
enhancement New feature or request Internal-Issue-Created An issue has been created in NextGen's internal issue tracker RS-10458 triaged

Comments

@joshmc82
Copy link

joshmc82 commented Apr 4, 2023

Is your feature request related to a problem? Please describe.
Now that Mirth Connect supports using the database for storing the configurationMap data, that should be the default behavior.

Describe your use case
It makes failover and recover a lot easier if I don't have to care about the file system I've installed on. This is also a critical change for containerized instances.

Describe the solution you'd like
Add configurationmap.location=database to the default mirth.properties file

Describe alternatives you've considered
Manually add it during every deployment before setting up the environment

Additional context
N/A

@joshmc82 joshmc82 added the enhancement New feature or request label Apr 4, 2023
@pladesma pladesma added triaged Internal-Issue-Created An issue has been created in NextGen's internal issue tracker RS-10458 labels Apr 5, 2023
@jonbartels
Copy link
Contributor

@joshmc82 I have a branch on my fork for this change. I have not tested it locally yet. Ran out of motivation before the build completed.

Opinions and code reviews welcome - https://github.com/jonbartels/connect/tree/5746-configmap-to-db-default

The getString(property, default) is a better pattern than the old way of doing null checks.

I kind of want to change it to use StringUtils.equals instead of yoda conditions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request Internal-Issue-Created An issue has been created in NextGen's internal issue tracker RS-10458 triaged
Projects
None yet
Development

No branches or pull requests

3 participants