You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For JDBC datasources, we don't even try to connect to a database if the JDBC URL is not set
For Reactive datasources, we default to localhost and a DB-specific port if the Reactive URL is not set
This is inconsistent, and IMO the reactive behavior is at best unnecessary, at worst dangerous:
In dev mode, people should generally use dev services, so the URL will always be set, so this is irrelevant.
In prod mode, people will most likely need dedicated config -- specific DB name at the very least, and most likely authentication.
In either dev mode or prod, people might not want to connect to some arbitrary, default DB that just happens to be there, and potentially start messing with the database schema (e.g. with Hibernate).
What's more, this default is not documented at all:
I would suggest we align reactive datasources on the behavior of JDBC datasources.
Expected behavior
Reactive datasources should behave similarly to JDBC datasources when the reactive URL is unset. Or, to be precise, they should behave similarly to JDBC datasources after #41929 gets fixed:
Runtime startup should fail if such a datasource is statically injected.
Dynamic retrieval of such such a datasource through Arc should throw an exception.
Such a datasource should not appear in health checks.
Actual behavior
Runtime startup does not fail if such a datasource is statically injected.
Dynamic retrieval of such such a datasource through Arc does not throw an exception.
Such a datasource appears in health checks, with a DOWN status.
How to Reproduce?
I will add tests in #41929; I may send a separate PR with just the tests.
Output of uname -a or ver
No response
Output of java -version
No response
Quarkus version or git rev
No response
Build tool (ie. output of mvnw --version or gradlew --version)
No response
Additional information
No response
The text was updated successfully, but these errors were encountered:
Yes, fine with me. This default is inherited from bare Vert.x SQL Clients, but it makes sense to align behavior of JDBC/Reactive datasources in Quarkus
yrodiere
changed the title
Reactive datasource defaults to localhost and DB-specific port for quarkus.datasource.reactive.url
Reactive datasource should not have a default for quarkus.datasource.reactive.urlSep 26, 2024
Describe the bug
I noticed while working on #41929 that:
This is inconsistent, and IMO the reactive behavior is at best unnecessary, at worst dangerous:
What's more, this default is not documented at all:
I would suggest we align reactive datasources on the behavior of JDBC datasources.
Expected behavior
Reactive datasources should behave similarly to JDBC datasources when the reactive URL is unset. Or, to be precise, they should behave similarly to JDBC datasources after #41929 gets fixed:
Actual behavior
How to Reproduce?
I will add tests in #41929; I may send a separate PR with just the tests.
Output of
uname -a
orver
No response
Output of
java -version
No response
Quarkus version or git rev
No response
Build tool (ie. output of
mvnw --version
orgradlew --version
)No response
Additional information
No response
The text was updated successfully, but these errors were encountered: