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

Added additional url params in JdbcDatabaseContainer (#1802) #1874

Merged
merged 19 commits into from May 21, 2020
Merged

Added additional url params in JdbcDatabaseContainer (#1802) #1874

merged 19 commits into from May 21, 2020

Conversation

eaxdev
Copy link
Contributor

@eaxdev eaxdev commented Sep 15, 2019

Added the ability to add additional parameters to the URL in JDBC containers

@eaxdev eaxdev changed the title Add additional url params in MySQLContainer (#1802) Added additional url params in MySQLContainer (#1802) Sep 15, 2019
@rnorth
Copy link
Member

rnorth commented Sep 16, 2019

Thanks @eaxdev!

I'm curious about a couple of things.

The connection string that you're modifying is usually only used during Testcontainers initial readiness checks for the container and running of init scripts. The expectated usage of the current API is that your normal code would call getJdbcUrl(), append any query params you wish, and obtain a connection yourself. The createConnection(String) method can also be used, and accepts query params in urlencoded form.

So firstly, what is the use case that means that the current API is not sufficient? I'm afraid I'm not quite clear on this yet.

Secondly, if we do this, is there a specific reason not to support it for other JDBC container types? It seems that it would almost be easier to support it all-round!

@eaxdev
Copy link
Contributor Author

eaxdev commented Sep 17, 2019

Hi, @rnorth!

  1. Yes, I also think that it is necessary to add this logic in the getJdbcUrl() method. And this is more correct. But as @knutwannheden described in issue Cannot connect to MySQL with time zone #1764 when the container is initialization, it also needs specific properties from the URL, such as serverTimezone, without this in its case the container does not start. Therefore, the same settings are required and in the constructUrlForConnection method.

  2. Yes, that's a good idea. I could also do this for for other JDBC container types that support parameters in the URL.

@knutwannheden
Copy link

Some comments from my side:

  1. I would indeed expect the logic to be implemented directly in JdbcDatabaseContainer. I now already had to extend the MySQLContainer and the MariaDBContainer for the same reason.
  2. I also think the logic should be implemented in constructUrlForConnection(String), because it also needs to work when called by JdbcDatabaseContainer#waitUntilContainerStarted(), where createConnection(String) is called with the empty string as the argument.
  3. I think there should be Javadoc for withUrlParam() which makes it clear whether the arguments are expected to be encoded or not (expecting encoded values probably makes more sense, as some JDBC drivers may not decode according to the URL specification?).

@rnorth
Copy link
Member

rnorth commented Sep 23, 2019

Thanks for your input @knutwannheden - I agree with your points.

@eaxdev, would you be OK to follow up with changes?
Thank you both!

@eaxdev
Copy link
Contributor Author

eaxdev commented Sep 24, 2019

Hi, @rnorth! Yes, I'm ready to follow up with changes. But still I want to clarify the final requirements:

  1. Add this logic to two methods: getJdbcUrl() and constructUrlForConnection().
  2. Add this logic to other JDBC container types, not just MySQL.

Did I understand the problem correctly? Thanks!

@knutwannheden
Copy link

@rnorth It looks like @eaxdev is still waiting for some input here. Just in case you missed it. Thanks.

@eaxdev
Copy link
Contributor Author

eaxdev commented Oct 16, 2019

Hi, @rnorth!

I added support it for other JDBC container types. See, please. Thank!


public SELF withUrlParam(String paramName, String paramValue) {
throw new UnsupportedOperationException();

Choose a reason for hiding this comment

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

Why can't the implementation of this method be pulled up here?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, that's a good idea. I will fix it.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This is done. I did it.

@rnorth
Copy link
Member

rnorth commented Oct 17, 2019

We seem to have some test failures around the MS SQL Server container - any ideas?

@eaxdev
Copy link
Contributor Author

eaxdev commented Oct 17, 2019

@rnorth , Yes, Yes. I already got it. I'm already fixing...

@eaxdev
Copy link
Contributor Author

eaxdev commented Oct 18, 2019

@rnorth, I fixed it. Now all tests pass

@eaxdev eaxdev changed the title Added additional url params in MySQLContainer (#1802) Added additional url params in JdbcDatabaseContainer (#1802) Oct 18, 2019
@@ -46,6 +46,8 @@ public PostgreSQLContainer(final String dockerImageName) {
@Override
protected void configure() {
addExposedPort(POSTGRESQL_PORT);
// Disable Postgres driver use of java.util.logging to reduce noise at startup time
withUrlParam("loggerLevel", "OFF");

Choose a reason for hiding this comment

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

I haven't investigated what exactly this does, but it looks a bit weird. I can understand if by default the logging level should not be DEBUG or so, but I would definitely like to see errors and probably also warnings by default (i.e. without having to investigate how to change this manually).

Please disregard if I missed something.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It used to be in the getJdbcUrl method like this:

return "jdbc:postgresql://" + getContainerIpAddress() + ":" + getMappedPort(POSTGRESQL_PORT) + "/" + databaseName + "?loggerLevel=OFF";

I just moved it to the configure() method.

I'm guessing the logger was turned off on purpose to remove the noise at the start of the container.

@@ -90,6 +90,11 @@ public OracleContainer withPassword(String password) {
return self();
}

@Override
public OracleContainer withUrlParam(String paramName, String paramValue) {

Choose a reason for hiding this comment

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

Since some DBs like Oracle don't support URL parameters, but do support Properties parameters, I think it is worth considering renaming this method to withParam() or withJdbcParam(), so that client code doesn't have to call withUrlParameter() for some DBs and something like withPropertiesParam() for others (assuming that will be also supported in the future). I just think this would be worth considering.

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 think this is not entirely correct. What do you think about that, @rnorth ? Thx!

Copy link
Member

Choose a reason for hiding this comment

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

Sorry to take so long to come back to this PR to break the tie...

I think the current form is reasonable; Oracle does not support JDBC URL parameters (in the normal sense of a URL parameter, anyway). Also, we don't support setting connection properties for the Oracle driver.

It's good to think about the future case of being agnostic of whether the connection params are set in the URL or as properties. However, I think that:

  1. the params themselves are so database-specific that it's rarely going to be possible to write them generically, and
  2. trying to support both URL params and properties via one method is going to tie us in knots if we ever actually support pass-through of properties - we're not going to know which params go where.

Choose a reason for hiding this comment

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

Makes sense. Let's tackle that problem with connection properties separately. From my POV this commit looks good to go!

@rnorth rnorth self-assigned this Nov 1, 2019
@knutwannheden
Copy link

Any status update on this PR? Would be nice if it could get integrated in some form.

@stale
Copy link

stale bot commented Apr 11, 2020

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you believe this is a mistake, please reply to this comment to keep it open. If there isn't one already, a PR to fix or at least reproduce the problem in a test case will always help us get back on track to tackle this.

@stale stale bot added the stale label Apr 11, 2020
@kiview
Copy link
Member

kiview commented Apr 11, 2020

@rnorth WDYT on how to proceed here? You were the most involved one.

@stale stale bot removed the stale label Apr 11, 2020
@eaxdev
Copy link
Contributor Author

eaxdev commented May 15, 2020

@rnorth Which status of this PR? Is something wrong with him?

@rnorth
Copy link
Member

rnorth commented May 16, 2020

Eugh, sorry I let this slip through the cracks. I'll check out the merge conflicts and resolve.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants