Conversation
…IG. IQSS#7980 Previously, with Dataverse software 5.3, the option to configure the database connection has been moved into the codebase. Admins can set details via MicroProfile Config. With updating to Payara 5.2021.4, we can provide default values for the connection details. Before, this had been tried with adding them to META-INF/microprofile-config.properties. However, this is not possible due to the timing of resource creation in the application server vs. reading the properties file. IQSS#7980
As requested by @pdurbin, the long list was quite overwhelming. It's now damped down to 12 options in 3 subsubsections of the docs.
The avoid hacky parameter additions via the database name, this commit adds support for adding parameters to the JDBC URL. It defaults to empty (no parameters).
With the addition of the advanced (but proprietary, Payara-only) settings for database connection monitoring, the non-present default for connection validation triggered unnecessary log clutter. Adding an empty default makes these go away and is inline with the default of Payara.
5144d16 to
8350af2
Compare
|
sizing: Waiting on Oliver input. He is out today. |
|
Phil is going to talk with Oliver to see if this can be lowered in priority in the community column |
|
I've just merged latest That said, yes, it may move down the column. I have no urgent business requiring this ATM. |
You know what? Based on comments by @landreev and @donsizemore in the issue regarding the usefulness of By the way, there's a failing test but I suspect it's unrelated: |
|
Pdurbin reviewed and sized. Moving to sprint ready column. |
pdurbin
left a comment
There was a problem hiding this comment.
Looks good.
The most immediate real world use case for this PR seems to be sslmode=require (see the issue this PR closes) so I mentioned this in the docs.
I did some cursory testing but didn't test the new default database name and user (both "dataverse") though I left a comment about how we could probably test this.
I love the new rst table format, by the way. Seems much easier than keeping the correct number of spaces here or there!
|
|
||
|
|
||
|
|
||
| Database Persistence |
There was a problem hiding this comment.
The docs are great but I wonder if they should be moved to "Advanced Installation" because the default database setup works fine and the list of steps before "going live" is getting longer and longer. We can defer this doc change for now. I created a dedicated issue for later:
| * - dataverse.db.parameters | ||
| - Connection parameters, see `Postgres JDBC docs <https://jdbc.postgresql.org/documentation/head/connect.html>`_ | ||
| Note: you don't need to provide the initial "?". | ||
| - *Empty string* |
There was a problem hiding this comment.
I tried putting the following in domain.xml...
<jvm-options>-Ddataverse.db.parameters=sslmode=require</jvm-options>
... and it seems to have worked. Dataverse failed to deploy and I get errors like this in server.log:
Connection could not be allocated because: The server does not support SSL.
Error in allocating a connection. Cause: Connection could not be allocated because: The server does not support SSL.
Exception while invoking class org.glassfish.ejb.startup.EjbApplication start method
javax.ejb.EJBException: javax.ejb.CreateException: Initialization failed for Singleton StartupFlywayMigrator
...
Caused by: org.flywaydb.core.internal.exception.FlywaySqlException: Unable to obtain connection from database: Error in allocating a connection. Cause: Connection could not be allocated because: The server does not support SSL.
SQL State : null
Error Code : 0
Message : Error in allocating a connection. Cause: Connection could not be allocated because: The server does not support SSL.
| * - dataverse.db.user | ||
| - The PostgreSQL user name to connect with. | ||
| - | ``dataverse`` | ||
| | (installer sets to ``dvnapp``) | ||
| * - dataverse.db.password | ||
| - The PostgreSQL users password to connect with. | ||
|
|
||
| **Please note the safety advisory above.** | ||
| - *No default* | ||
| * - dataverse.db.name | ||
| - The PostgreSQL database name to use for the Dataverse installation. | ||
| - | ``dataverse`` | ||
| | (installer sets to ``dvndb``) |
There was a problem hiding this comment.
I'm not sure how to see that the default database user and database are "dataverse".
To deploy this branch I used scripts/dev/dev-rebuild.sh which has the names the installer uses hard coded:
DB_NAME=dvndb
DB_USER=dvnapp
I guess I could try changing that script to this...
DB_NAME=dataverse
DB_USER=dataverse
... and then deleting these lines from domain.xml:
<system-property name="dataverse.db.user" value="dvnapp"></system-property>
<system-property name="dataverse.db.name" value="dvndb"></system-property>
That is, without these system properties configured, it sounds like the default database user and database name will be "dataverse".
There was a problem hiding this comment.
Yes. Sorry, but for container environments it really is common practice to use the application name for the database name. As the installer sets this explicitly for any installation out there, folks should be fine.
|
@poikilotherm Can you refresh from develop? Getting flyway errors on deployment. Thanks! |
|
@kcondon done! Refreshed! Ahhh. |
What this PR does / why we need it:
Create real defaults for the database connection, enable configuring advanced settings, add docs.
Which issue(s) this PR closes:
Closes #7980
Special notes for your reviewer:
Only in a few occasions people might have hit the regression.
Suggestions on how to test this:
asadmin create-system-properties "dataverse.db.log-jdbc-calls=true"Does this PR introduce a user interface change? If mockups are available, please link/include them here:
Nope.
Is there a release notes update needed for this change?:
🔋 included.
Additional documentation:
None.