Reactive Postgres Client extension

[tsegismont]

The Reactice Postgres Client is a client for Postgres with a straightforward API focusing on scalability and low overhead.

The goal of issue is to gather requirements for a Quarkus extension and discuss technical details.

• Expose a PgPool instance for all supported shims (bare, Axle, RxJava)
• Use quarkus datasource usual properties for configuration
• Use import.sql file if present

Open issues:

• how to make it clear to the user in the guide that datasource url is for configuring a reactive PgPool, using the reactive:postgres scheme?
• since the Reactive Pg Client is not an ORM, is it fine to use import.sql to execute DDL statements on startup?

[FroMage]

how to make it clear to the user in the guide that datasource url is for configuring a reactive PgPool, using the reactive:postgres scheme?

That would be fine, but it would prevent using both Hibernat eORM and reactive-pg-client in the same application. But I think it's OK: they're essentially two different drivers.

since the Reactive Pg Client is not an ORM, is it fine to use import.sql to execute DDL statements on startup?

Absolutely: it's even more useful precisely because it's not an ORM so we always need a file to create the schema.

[FroMage]

Note that my panache-rx branch already has some of those pieces, so feel free to steal them from there :)

[tsegismont]

Roger that Le jeu. 4 avr. 2019 à 17:24, Stéphane Épardaud <notifications@github.com> a écrit :

…

Note that my panache-rx branch already has some of those pieces, so feel free to steal them from there :) — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1862 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABbltqD2xzdI77kePlYG2cSR1AtB6ToTks5vdhlDgaJpZM4cdBYV> .

[Sanne]

it would prevent using both Hibernat eORM and reactive-pg-client in the same application. But I think it's OK: they're essentially two different drivers.

Why is that ok? And even two drivers should be possible to be used in the same application.

[Sanne]

since the Reactive Pg Client is not an ORM, is it fine to use import.sql to execute DDL statements on startup?

Sure why not. But I don't see why you relate it to "not being an ORM" :)

Automatically importing a sql script is some added value that ORMs often do but it's not defining them.

Incidentally, I'm not sure why the extension of the driver should do such things? It doesn't feel like such added value belongs in here.

We also have the Flyway extension, maybe it should integrate with that one if you want to provide a nicer "setup of the db" user experience.

[tsegismont]

Sure why not. But I don't see why you relate it to "not being an ORM" :)

Sorry it was not clear enough. I meant that both Hibernate and Panache extensions use the quarkus.hibernate-orm.database.generation property for DML.

Incidentally, I'm not sure why the extension of the driver should do such things? It doesn't feel like such added value belongs in here.

The extension would do nothing particular to discriminate DDL from DML statements. I was just wondering if using DDL statements in import.sql for the extension guide was fine.

We also have the Flyway extension, maybe it should integrate with that one if you want to provide a nicer "setup of the db" user experience.

I would definitely advise users to use Flyway in production, but that is not specific to the Reactive driver (I would advise users to use Flyway with Hibernate too).

If it's a blocker to have DDL in import.sql, then ok I'll look into Flyway but that sounds overkill to me for a getting started guide.

[Sanne]

hi @tsegismont ! no worries I'm not at all saying that having a DDL statement in there is a problem. I only made some questions :)

I'm just wondering if it's useful for a client extension to auto-import a script? As a user I wouldn't expect this functionality to be provided by a Quarkus extension, so I wonder how useful it is, and if people will be able to find that this capability exists.
Maybe such a capability belongs in the actual code of the Reactive Postgres Client ?

[tsegismont]

@Sanne I filed this issue after a discussion on quarkus-dev about #1816.

It's been agreed to create an extension (and not just a guide) providing:

• autoconfig
• db setup in development mode

The motivation is that Quarkus users get a cohesive experience, regardless of the type of application they are writing.

A lot people don't read manuals 🤷‍♂️ But I have planned to update the guide to talk about both features.

As for moving such capabilities upstream, in Vert.x land these things are left in users' hands.

[FroMage]

Why is that ok? And even two drivers should be possible to be used in the same application.

Well, sure, but that would be two different datasources, right?

[Sanne]

Why is that ok? And even two drivers should be possible to be used in the same application.

Well, sure, but that would be two different datasources, right?

Yes I agree! But you also said "it would prevent using both Hibernate ORM and reactive-pg-client" so I'm confused about that, as I see no reason why this would be prevented since - as you said just know - one can just declare two datasources.

[Sanne]

@tsegismont makes sense! I'm not opposing doing this, but I'll admit that I would have expected this to be left into "user's hands" like you said people normally do in "vertx land"

either way, fine by me - just asked to see if this was considered.

[tsegismont]

@Sanne @emmanuelbernard @FroMage it seems there is no consensus yet on what this extension should or shouldn't do. Trying to summarize the feedback received so far:

• on one hand, there is a will to make it easy for users to consume the Reactive Pg client (in the opinionated platform spirit)
• on the other hand, there is the feeling that the Reactive Pg client is comparable to a JDBC driver, and thus an extension should not provide ORM like features, especially if not present upstream.

I understand it may take some time to come to an agreement (given the dilemma not only applies to this extension but to any data client in general).

So let's move forward and narrow down the scope to:

• autoconfig parsing datasource url and common properties (eg max size)
• produce a bare/Axle/RxJava PgPool instance

We can revisit later, when all aspects (including usage of Flyway) have been considered by a larger group of people involved in data clients.

[cescoffier]

Hello,

On 6 Apr 2019, at 18:17, Thomas Segismont ***@***.***> wrote: @Sanne <https://github.com/Sanne> @emmanuelbernard <https://github.com/emmanuelbernard> @FroMage <https://github.com/FroMage> it seems there is no consensus yet on what this extension should or shouldn't do. Trying to summarize the feedback received so far: on one hand, there is a will to make it easy for users to consume the Reactive Pg client (in the opinionated platform spirit) on the other hand, there is the feeling that the Reactive Pg client is comparable to a JDBC driver, and thus an extension should not provide ORM like features, especially if not present upstream. I understand it may take some time to come to an agreement (given the dilemma not only applies to this extension but to any data client in general). So let's move forward and narrow down the scope to: autoconfig parsing datasource url and common properties (eg max size) produce a bare/Axle/RxJava PgPool instance

It would be a good start. There are a few adaptation to do regarding the JSON handling. It would be preferable to not have 2 different ways to handling JSON. I’m also wondering what would be the best approach to integrate the LISTEN feature (but I need to think about it a bit more)

We can revisit later, when all aspects (including usage of Flyway) have been considered by a larger group of people involved in data clients.

Does that mean the extension won’t support fixtures? I don’t have a strong opinion, but as a user, I love when such kind of thing works out of the box. Especially in the async world, checking if table exist or is empty can lead to a few nested callbacks.

…

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1862 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAYjfWf9Za-dQJC53TDVGEW246qXLKn6ks5veMidgaJpZM4cdBYV>.

[emmanuelbernard]

If I understand Thomas, the idea is to start with

Have the extension enlist the bean that reads the database properties (standard ones), and create the PgPool as @Inject-able.
Ideally make PgPoolOptions a default bean that will be made overridable by user apps at some point in the future CC @mkouba on describing how to do it across all extensions.

About the bare/Axle/RxJava, I'll let Clement quarlify. I thought we wanted to promote the Axle types but if we are to support all, then yes.

About import.sql vs/and FlyWay, indeed it does not seem to be an agreement. So let's do it in phase 2. (but log the issue)

[tsegismont]

Ideally make PgPoolOptions a default bean that will be made overridable by user apps at some point in the future CC @mkouba on describing how to do it across all extensions.

Would be glad if you could point me to an example in other extensions because I don't know what a default bean is.

About the bare/Axle/RxJava, I'll let Clement quarlify. I thought we wanted to promote the Axle types but if we are to support all, then yes.

We do it for the Vert.x and EventBus instances already. In the guides, we favor the Axle API, but all flavors have their merits depending on the use case.

About import.sql vs/and FlyWay, indeed it does not seem to be an agreement. So let's do it in phase 2. (but log the issue)

ok