Added support for listening to notifications #52
Conversation
| @@ -258,6 +267,11 @@ public TransactionStatus getTransactionStatus() { | |||
| return this.transactionStatus.get(); | |||
| } | |||
|
|
|||
| @Override | |||
| public Disposable addNotificationListener(Consumer<NotificationResponse> consumer) { | |||
There was a problem hiding this comment.
Isn't it better to expose Flux<NotificationResponse> here?
|
I'll take a look and provide some feedback, but this will be an M8 contribution, in line with discussion on the mailing list. |
nebhale
added
the
status: pending-design-work
|
Sorry for the long radio silence. It took us a while to sort out a few issues in the R2DBC project. With r2dbc/r2dbc-spi#35 we're envisioning a standardized approach for event providers (such as connection events or Pub/Sub notifications). It would make sense to expose What do you think? As this PR is here for quite some time, we should rebase it if the suggestion above makes sense. |
mp911de
removed
the
status: pending-design-work
Expose notification events as Flux<Notification>.
Connection sender, receiver = …;
Flux<Notification> listen = receiver.createStatement("LISTEN mymessage").execute()
.flatMap(PostgresqlResult::getRowsUpdated)
.thenMany(receiver.getNotifications());
Mono<Void> notify = sender.createStatement("NOTIFY mymessage, 'Hello World'").execute().flatMap(PostgresqlResult::getRowsUpdated).then()
[#52]
|
Thanks a lot. That's merged and polished now. |
It seems there is very little in the way of exposing Postgres asynchronous notifications (https://www.postgresql.org/docs/9.3/libpq-notify.html) via the client. This allows a consumer to be configured which is called each time a NotificationResponse is received. This allows r2dbc users to take advantage of basic pub/sub functionality via the Postgres LISTEN/NOTIFY mechanism (see tests for examples).
In terms of the API I'm not sure whether a Consumer is preferable or if it would be better to expose a Flux directly.