Add getR2dbcUrl helper method to JdbcDatabaseContainer

Module

Core

Problem

I might've been chosen the wrong module, sorry for that, haven't found one for all RDBMS containers.

There is a convenient method, getJdbcUrl in JdbcDatabaseContainer. The problem however, if I'm working with R2DBC the connection string schema is different. Currently, I have to create an R2DBC connection string myself, which is a bit tedious.

Solution

It would be great to have a similar method in JdbcDatabaseContainer, like getR2dbcUrl that would construct the R2DBC compliant connection string.

Benefit

This would make integration with R2DBC drivers more seamless and provide better developer experience.

Alternatives

The alternative, I think, is to create the connection string manually, which might be fine, not a big deal, until you have to do it over and over again, in which case it became really frustrating.

Would you like to help contributing this feature?

Yes

I would say this sounds very magical and has little practical value. Although most databases will only have one R2DBC Driver, there may actually be multiple JDBC Drivers for a single database. For example, for the third-party PostgreSQL JDBC Driver https://github.com/awslabs/aws-postgresql-jdbc , there is obviously only jdbc:postgresql:aws://<host>:5432/<database>, but there is no corresponding r2dbc:postgresql:aws://<host>:5432/<database>.

@linghengqian

@linghengqian I do not understand your point at all. R2DBC is a spec. It is a spec. The format of such URL is predefined for each implementation. Therefore, it does not matter whether one RDBMS has 0, 1 or multiple R2DBC drivers - they still will comply to the standard.

I think adding this is utterly clear and portable, in contrast to example with JDBC URL which is not standardized by a single spec. If we care about the user, who is trying to get R2DBC URL for the database, which actually does not have the R2DBC driver - who's fault that actually is?

Hi, thanks for the suggestion. I don't think this is feasible nowadays, the change must be done in R2DBCDatabaseContainer. But, it would be used R2DBCDatabaseContainer.getR2dbcUrl(PostgreSQLR2DBCDatabaseContainer.getOptions(postgresContainer)), which I don't think is friendly enough.

Testcontainers R2dbc integrations in spring-boot and micronaut test-resources are based on PostgreSQLR2DBCDatabaseContainer.getOptions(postgresContainer)

Other alternative is to implement getR2dbcUrl in each implementation but given the spec I would rather prefer the having a general method that applies to all.

Given the ecological situation of r2dbc, I don't think r2dbc will continue to develop healthily, and testcontainers do not need to consider the interoperability of r2dbc and jdbc. An example is that https://central.sonatype.com/artifact/io.r2dbc/r2dbc-h2 , which is used to replace the h2database jdbc driver, has not had a new version for more than a year.
From the perspective of 2024, the ADBC Driver involved in https://github.com/apache/arrow-adbc is more likely to become the real future of database clients, because ADBC Driver is not designed just for Java, it also has specifications for a number of programming languages such as C/Glib, C++, C#, Go, etc. for designing and implementing drivers. See https://arrow.apache.org/docs/format/ADBC.html .

I honestly do not understand how the case for comparison of arrow-adbc and r2dbc specification can be made. These are meant for different things, that does not make any sense.

Apart from that, solving this issue does not seem to be that complicated (but I might be wrong). However, it is indeed a bit of shame that so much time spent for discussion and arguments for such a small feature.

@eddumelendez

The Testcontainers team has no negative sentiment towards R2DBC and no opinion with regards to its future direction. We aren't not opposed to the feature request from a user perspective at all, we just need to agree on the design/API.

For me it sounds like it could be possible to implement getR2dbcUrl() in JdbcDatabaseContainer and then have the individual container classes implement some schema specific getters. These are also totally fine to be opinionated (i.e. with regards to the driver), users can still opt to manually create the connection string instead and our getJdbcUrl() method is also highly opinionated.

Hi, thanks for the suggestion. I don't think this is feasible nowadays, the change must be done in R2DBCDatabaseContainer.

@eddumelendez Maybe you can elaborate why it would not be feasible with the current design?

@eddumelendez

I took another look and the following method can be provided

Example using MSSQLR2DBCDatabaseContainer

public static String getR2dbcUrl(MSSQLServerContainer<?> container) {
    ConnectionFactoryOptions options = getOptions(container);
    return String.format("...", options.getValue(Option.valueOf("")));
}

every R2DBCDatabaseContainer implementation must provide the static method.

@eddumelendez Maybe you can elaborate why it would not be feasible with the current design?

I would like to enforce the implementation by declaring the method in the interface but more breaking changes would be require. I think the suggestion above will cover the current need.

@mipo256

We could implement the method getR2dbcUrl() in the R2DBCDatabaseContainer interface with a default implementation that throws an UnsupportedOperationException, to avoid it being a breaking change to potential 3rd party implementations of the interface out there.

@mipo256 For your use case, is having this method on R2DBCDatabaseContainer appropriate, or would you want/need it on JdbcDatabaseContainer? I think also on JdbcDatabaseContainer, we could follow such an approach with a default UnsupportedOperationException implementation to avoid breaking changes.

We have agreed on adding a new static method on each R2DBCDatabaseContainer implementation

For example, under MySQLR2DBCDatabaseContainer

public static String getR2dbcUrl(MySQLContainer<?> container) {
    return ...;
}

Current users used to do MySQLR2DBCDatabaseContainer.getOptions(container), so, in order to make this discoverable we decided to proceed with static method.

Please free free to submit a PR.

submit a PR #9569

feat(module/mariadb): Add getR2dbcUrl() to MariaDBR2DBCDatabaseContainer

Add getR2dbcUrl() method to JdbcDatabaseContainer (testcontainers#8797)

feat: add getR2dbcUrl() helper to PostgreSQL, MySQL, and MariaDB R2DB…

@eddumelendez

Hi @eddumelendez, I noticed there are now several PRs open for #8797 with slightly different scopes. Before more work diverges, would it help to clarify the expected scope for this issue?

My understanding from your previous comment is that the preferred direction is:

a new static method on each R2DBCDatabaseContainer implementation
coverage for PostgreSQL, MySQL, and MariaDB
support for both the modern and compatibility packages
MSSQL handled separately, given the current R2DBC limitations

I opened #11571 following that direction, but I’m happy to align with a narrower or different scope if that’s preferred.

Hi, I'd like to work on this issue. I am a first-time contributor and if possible can you confirm that this is still available and give any guidance on the preferred approach?

I don't think there's any point in adding r2dbc support functions. Most r2dbc libraries are not actively maintained.

@eddumelendez

hii @eddumelendez @linghengqian @kiview sir ,please review this pr #11969 .

Hi can I work on this issue?

Navigation Menu

Repository navigation

Add getR2dbcUrl helper method to JdbcDatabaseContainer #8797

Module

Problem

Solution

Benefit

Alternatives

Would you like to help contributing this feature?

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Add getR2dbcUrl helper method to JdbcDatabaseContainer #8797

Description

Module

Problem

Solution

Benefit

Alternatives

Would you like to help contributing this feature?

Activity

linghengqian commented on Jul 21, 2024

mipo256 commented on Jul 22, 2024

eddumelendez commented on Aug 13, 2024

linghengqian commented on Oct 4, 2024

mipo256 commented on Oct 4, 2024

kiview commented on Oct 7, 2024

eddumelendez commented on Oct 8, 2024

kiview commented on Oct 14, 2024

eddumelendez commented on Oct 17, 2024

DHKIM-0511 commented on Nov 26, 2024

PreAgile commented on Mar 18, 2026

DeepakJaiswar25 commented on May 24, 2026

linghengqian commented on May 24, 2026

Rajkaran-122 commented on Aug 22, 2026

sakethbalijepalli commented on Sep 23, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions