Set quarkus.datasource.db-kind property in PostgreSql Service Binding

[johnpoth]

…rviceBindingConverter

Fixes #14327

Thanks !

[ghost]

Thanks for your pull request!

The title of your pull request does not follow our editorial rules. Could you have a look?

• title should not end up with ellipsis (make sure the title is complete)
• title should preferably start with an uppercase character (if it makes sense!)
• title should not contain an issue number (use 'Fix Allow * expression for quarkus:add-extension #1234' in the description instead)

This message is automatically generated by a bot.

[geoand]

Good catch!

[geoand]

Actually, I remember why this was not done in the first place and why it's wrong.

quarkus.datasource.db-kind is a build-time property. So you need to have it set during build, it doesn't have any effect when setting at runtime.

cc @gsmet

[gsmet]

I think the only thing you can do is check the build time value and throw an error if it's not consistent.

[geoand]

I don't think that provides much value TBH

[johnpoth]

@geoand, thanks!

@gsmet when creating a default datasource, do all database properties need to be set at build-time (password, username, url, db-kind...) or just the db-kind? While testing it seems it's the former

[geoand]

I am pretty sure you don't need the runtime properties (like the URL, the username etc.) set, but I could be mistaken and maybe you need some dummy values set

[johnpoth]

@geoand gotcha. I see two ways of solving this:

1] Take quarkus.datasource.db-kind into account at runtime

2] Read the Service Bindings at build time as well as at runtime

If you'd like I can do an initial implementation

[geoand]

@geoand gotcha. I see two ways of solving this:

1] Take quarkus.datasource.db-kind into account at runtime

Unfortunately this is not an option: Quarkus needs to know a lot of stuff at buid time

2] Read the Service Bindings at build time as well as at runtime

If you'd like I can do an initial implementation

But if you do this, properties won't be available at runtime, no?

I might have missed this, but what is the original problem you are trying to solve?

[johnpoth]

@geoand I was thinking of adding the kubernetes service binding as a config source at build time too. That way the user only has to use the service binding for a default datasource to be created and doesn't have to add something else to his config or command line. In our case, the user has to set quarkus.datasource.db-kind correctly. I think this would make the user experience better. Hope this makes sense, let me know what you think thanks !

[geoand]

Ah, now I think I understand.

So you basically want the following:

When a user has the quarkus-kubernetes-service-binding extension and quarkus-jdbc-postgresql, then have quarkus.datasource.db-kind set to postgresql automatically?

I think that it's a good idea. @gsmet how does that sounds to you?

[geoand]

I opened a draft PR showing the approach I mentioned above #14393.

@gsmet care to comment on that since you are the SME on all things datasource?

[johnpoth]

@geoand exactly! Maybe if there are several datasources configured by service bindings then set the datasource name to the servicebinding name or something (but keeping a default datasource in simple use is nice to have IMO). Thanks !

[geoand]

Currently we are not implementing multiple database resources - that is a next thing we need to look into