-
Notifications
You must be signed in to change notification settings - Fork 531
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
Conversation
Kudos, SonarCloud Quality Gate passed! |
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", |
There was a problem hiding this comment.
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);
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
@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. |
There was a problem hiding this 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?
3edb0ad
to
451188a
Compare
I think this might need to be updated too: https://github.com/cBioPortal/cbioportal/blob/master/docker/web-and-data/docker-entrypoint.sh#L27-L33 |
Kudos, SonarCloud Quality Gate passed! |
core/src/main/java/org/mskcc/cbio/portal/dao/JdbcDataSource.java
Outdated
Show resolved
Hide resolved
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 |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this 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 😃
@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 |
4ecb380
to
a433c26
Compare
Needed for flexible configuration of connection parameters required to run MySQL8.
There was a problem hiding this 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
Kudos, SonarCloud Quality Gate passed! 0 Bugs 0.0% Coverage 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. |
Merging this pull request. The localdb tests are failing because it's not using the latest URL format. Related pull request: |
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:
Verification
MSK tasks:
The Hyve tasks: