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

Configure database connection via db.connection_string param #10037

Merged
merged 2 commits into from
Aug 25, 2023

Conversation

pvannierop
Copy link
Contributor

@pvannierop pvannierop commented Feb 19, 2023

This update is needed to allow connection parameters required to run MySQL8.

Problem

In order to run MySQL 8 additional parameters must be provided to the database connection. At present similar parameters (e.g., db.use_ssl) are provided via dedicated properties in portal.properties and, by extension, in java class DatabaseProperties.

Solution

In order to make it easier to provide custom database connection parameters, I propose in this PR to leverage the existing db.connection_url parameter (that is unused as far as I can see) and make this the required way of configuring the connection. The db.user , db.password and db.driver properties will still be used. The db.host, db.database, db.port and db.use_ssl properties become obsolete.

This PR will also update the python migration script to run migration using the db.connection_string property. The python importer scripts all rely on confguration at the level of the Java code, and do not require update.

Backward compatibility

This implementation is backwards compatible with configuring with the legacy db.host, db.database, db.port and db.use_ssl properties.

Deprecation warning

A deprecation warning was added for the legacy style database connection params:

1:41:25.713 [RMI TCP Connection(2)-127.0.0.1] INFO  o.m.c.portal.util.GlobalProperties - Successfully read properties file

----------------------------------------------------------------------------------------------------------------
-- Deprecation warning:
-- You are connecting to the database using the deprecated 'db.host', 'db.portal_db_name' and 'db.use_ssl' properties.
-- Please use the 'db.connection_string' instead (see https://docs.cbioportal.org/deployment/customization/portal.properties-reference/).
----------------------------------------------------------------------------------------------------------------

11:41:25.718 [RMI TCP Connection(2)-127.0.0.1] INFO  o.s.c.s.PostProcessorRegistrationDelegate$BeanPostProcessorChecker - Bean 'businessDataSource' of type [org.mskcc.cbio.portal.dao.JdbcDataSource] is not eligible for getting processed by all BeanPostProcessors (for example: not eligible for auto-proxying)
...
11:41:29.012 [RMI TCP Connection(2)-127.0.0.1] INFO  o.s.web.context.ContextLoader - Root WebApplicationContext initialized in 6066 ms

----------------------------------------------------------------------------------------------------------------
-- You are connecting to the OncoKB public instance which does not include any therapeutic information.
-- Please consider obtaining a license to support future OncoKB development by following https://docs.cbioportal.org/2.4-integration-with-other-webservices/oncokb-data-access.
-- Thank you.
----------------------------------------------------------------------------------------------------------------

<6>Initializing Spring DispatcherServlet 'api'
11:41:29.079 [RMI TCP Connection(2)-127.0.0.1] INFO  o.s.web.servlet.DispatcherServlet - Initializing Servlet 'api'

Verification

MSK tasks:

  • Java part
    • (backward compatible) importers
    • (backward compatible) backend spring app database connection
  • (backward compatible) local backend migration script
  • deployments (beta portal)
  • internal usage

The Hyve tasks:

  • docker and docker-compose
    • backend database connection
    • migration script is still working

@sonarcloud
Copy link

sonarcloud bot commented Feb 19, 2023

Kudos, SonarCloud Quality Gate passed!    Quality Gate passed

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 0 Code Smells

0.0% 0.0% Coverage
0.0% 0.0% Duplication

@pvannierop
Copy link
Contributor Author

Assert.hasText(database, errorMessage("database", "db.database") +
" Or preferably, set the 'db.connection_string' and remove 'db.host', 'db.database' and 'db.use_ssl (best practice).");
connectionURL = String.format(
"jdbc:mysql://%s/%s&zeroDateTimeBehavior=convertToNull&useSSL=%s",
Copy link
Contributor

@n1zea144 n1zea144 Feb 21, 2023

Choose a reason for hiding this comment

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

@pvannierop This may be because I updated my local JDBC driver to 8.0.31, but I also had to add allowLoadLocalInfile=true to allow the bulk loader to work properly.

Related, I also had to update a prepared statement in MySQLbulkLoader.flushAll to get this method to work:

stmt = con.prepareStatement("SELECT @@foreign_key_checks;", ResultSet.TYPE_SCROLL_SENSITIVE, ResultSet.CONCUR_UPDATABLE);

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@n1zea144 The idea of this PR is that when you have the need for these params, you should provide the full connection string with the db.connection_string parameter, rather than specifying the 'legacy' db.host, db.use_ssl, etc. Remember that allowLoadLocalInfile=true is considered as a security risk. Activation as a default is not the way to go in my opinion.

Related, I also had to update a prepared statement in MySQLbulkLoader.flushAll to get this method to work:

stmt = con.prepareStatement("SELECT @@foreign_key_checks;", ResultSet.TYPE_SCROLL_SENSITIVE, ResultSet.CONCUR_UPDATABLE);

That is strange. I could load a study w/o making these changes. How could that be?

Copy link
Member

Choose a reason for hiding this comment

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

re allowLoadLocalInfile=true - I guess we would apply this just for the importer? Doesn't seem like much of a security risk in that setting

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I guess we would apply this just for the importer
Correct

@pvannierop
Copy link
Contributor Author

@inodb The integration test fails because there is a missing Python dependency. This test will automatically become green when the new docker image is pushed to Dockerhub that has this dependency.

Copy link
Member

@dippindots dippindots left a comment

Choose a reason for hiding this comment

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

@pvannierop Thanks for making this pr. The JDBC part looks good to me, and I can see that's backward compatible, we can still use the old property file. But I don't know why don't we also make migrate_db.py backward compatible. Maybe I missed some important things, could you help me understand this?

core/src/main/scripts/migrate_db.py Outdated Show resolved Hide resolved
@inodb
Copy link
Member

inodb commented Apr 5, 2023

@sonarcloud
Copy link

sonarcloud bot commented Apr 20, 2023

Kudos, SonarCloud Quality Gate passed!    Quality Gate passed

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 5 Code Smells

0.0% 0.0% Coverage
0.0% 0.0% Duplication

then
echo "The portal.properties file defines both db.connection_string and (one of) db.host, db.portal_db_name and "
echo "db.use_ssl. Please configure with either db.connection_string (preferred), or db.host, db.portal_db_name and db.use_ssl."
exit 1
Copy link
Contributor

Choose a reason for hiding this comment

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

We're promising backwards-compatibility but that's not true: if staying with properties as they are right now, the error message in line 64 will show up (since we have both obsolete and db.connection_string properties defined).

Removing the obsolete properties and leaving db.connection_string will not work, since the value of this property needs to be changed too (from jdbc:mysql://localhost:3306/ to jdbc:mysql://localhost:3306/cbioportal?useSSL=false).

If the user removes the db.connection_string and keeps the obsolete properties as they are in their setup, then the promised backwards compatibility comes into play. But since we want to prioritise using the new setup (db.connection_string), and the user needs to modify portal.properties anyway, maybe it makes more sense to force to use db.connection_string with the correct format and clean up the usage of the obsolete properties?

@inodb What do you think?

Copy link
Member

Choose a reason for hiding this comment

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

@pvannierop How about we don't allow db.connection_string shows up with one of 'db.host', 'db.portal_db_name', and 'db.use_ssl' properties? If that's the case, we throw an error and point out that the users should use db.connection_string only instead.

Copy link
Member

Choose a reason for hiding this comment

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

I know this is probably not 100% backward compatible, but I guess it's fine.

Copy link
Contributor

@oplantalech oplantalech left a comment

Choose a reason for hiding this comment

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

@dippindots For me it's ready to be merged 😃

@dippindots
Copy link
Member

@oplantalech Thanks for help testing the docker part. I also have done my testing for the local build. And it looks good, this is currently pending @sheridancbio's testing on our internal importing code compatibility. I will work with @sheridancbio to finish the testing and then let you know.

@oplantalech Do you have any ideas about the failing tests? I think the Labeler test is fine. But We should figure out why Core tests and Integration tests are failing before we merge this.

Needed for flexible configuration of connection parameters required to run MySQL8.
Copy link
Member

@dippindots dippindots left a comment

Choose a reason for hiding this comment

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

@pvannierop It looks all good to me, just the localdb tests are not working, but I guess that's because we haven't updated the cbioportal-docker-compose repository yet. I created a pull request to make the related changes, could you help to take a look? https://github.com/cBioPortal/cbioportal-docker-compose/pull/22/files

I will include this update in the next release. @inodb @pvannierop Just wondering maybe we should update software's minor version to 5.4.0 because based on our documentation, this change might require additional effort for a deployer of cBioPortal

docs/Migration-Guide.md Outdated Show resolved Hide resolved
@sonarcloud
Copy link

sonarcloud bot commented Aug 25, 2023

Kudos, SonarCloud Quality Gate passed!    Quality Gate passed

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 2 Code Smells

0.0% 0.0% Coverage
0.0% 0.0% Duplication

warning The version of Java (11.0.20) you have used to run this analysis is deprecated and we will stop accepting it soon. Please update to at least Java 17.
Read more here

@dippindots
Copy link
Member

Merging this pull request. The localdb tests are failing because it's not using the latest URL format. Related pull request:
frontend: cBioPortal/cbioportal-frontend#4710
cbioportal-docker-compose: cBioPortal/cbioportal-docker-compose#22

@dippindots dippindots merged commit e260eaa into cBioPortal:master Aug 25, 2023
12 of 14 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants