Jooq reactive fetching using r2dbc driver - jooq

My query looks like (using JOOQ v 3.15):
override fun getCredentialsById(id: Long): Mono<UserCredentialsModel> {
return Mono.from {
dsl.select(
USER_CREDENTIALS.ID,
USER_CREDENTIALS.EMAIL,
USER_CREDENTIALS.PHONE,
USER_CREDENTIALS.LOGIN,
USER_CREDENTIALS.PASSWORD)
.from(USER_CREDENTIALS)
.where(USER_CREDENTIALS.ID.eq(id))
.and(USER_CREDENTIALS.IS_ACTIVE.eq(true))
.fetchInto(UserCredentialsModel::class.java)
}
}
JOOQ config:
#Bean
fun createContext(): DSLContext {
return DSL.using(connection)
}
where connection is io.r2dbc.spi.ConnectionFactory
and I`m getting an exception:
org.jooq.exception.DetachedException: Attempt to execute a blocking method (e.g. Query.execute() or ResultQuery.fetch()) when only an R2BDC ConnectionFactory was configured
How should I then fetch my query result into Kotlin data class (or Java JOOQ`s POJO) in reactive style?

When using jOOQ reactively, you should never call any blocking methods, such as ResultQuery.fetchOneInto(Class). That method is just a convenience method for ResultQuery.fetchOne() and then Record.into(Class). Nothing keeps you from calling Record.into(Class) yourself, neither in the blocking world, nor in the non-blocking world.
So, use your usual reactor library methods to map stream contents:
mono.map { r -> r.into(UserCredentialsModel::class.java) }
Or, in a complete example:
return Mono.from {
dsl.select(
USER_CREDENTIALS.ID,
USER_CREDENTIALS.EMAIL,
USER_CREDENTIALS.PHONE,
USER_CREDENTIALS.LOGIN,
USER_CREDENTIALS.PASSWORD)
.from(USER_CREDENTIALS)
.where(USER_CREDENTIALS.ID.eq(id))
.and(USER_CREDENTIALS.IS_ACTIVE.eq(true))
} .map { r -> r.into(UserCredentialsModel::class.java) }

Without testing I would say it should be
return Mono.from(
dsl.select(
USER_CREDENTIALS.ID,
USER_CREDENTIALS.EMAIL,
USER_CREDENTIALS.PHONE,
USER_CREDENTIALS.LOGIN,
USER_CREDENTIALS.PASSWORD)
.from(USER_CREDENTIALS)
.where(USER_CREDENTIALS.ID.eq(id))
.and(USER_CREDENTIALS.IS_ACTIVE.eq(true)));

You can try .toMono().subscribe()
dsl.select(
USER_CREDENTIALS.ID,
USER_CREDENTIALS.EMAIL,
USER_CREDENTIALS.PHONE,
USER_CREDENTIALS.LOGIN,
USER_CREDENTIALS.PASSWORD)
.from(USER_CREDENTIALS)
.where(USER_CREDENTIALS.ID.eq(id))
.and(USER_CREDENTIALS.IS_ACTIVE.eq(true))
.fetchInto(UserCredentialsModel::class.java)
.toMono().subscribe()

Related

the right way to return a Single from a CompletionStage

I'm playing around with reactive flows using RxJava2, Micronaut and Cassandra. I'm new to rxjava and not sure what is the correct way to return a of List Person in the best async manner?
data is coming from a Cassandra Dao interface
public interface PersonDAO {
#Query("SELECT * FROM cass_drop.person;")
CompletionStage<MappedAsyncPagingIterable<Person>> getAll();
}
that gets injected into a micronaut controller
return Single.just(personDAO.getAll().toCompletableFuture().get().currentPage())
.subscribeOn(Schedulers.io())
.map(people -> HttpResponse.ok(people));
OR
return Single.just(HttpResponse.ok())
.subscribeOn(Schedulers.io())
.map(it -> it.body(personDAO.getAll().toCompletableFuture().get().currentPage()));
OR switch to RxJava3
return Single.fromCompletionStage(personDAO.getAll())
.map(page -> HttpResponse.ok(page.currentPage()))
.onErrorReturn(throwable -> HttpResponse.ok(Collections.emptyList()));
Not a pro of RxJava nor Cassandra :
In your first and second example, you are blocking the thread executing the CompletionStage with get, even if you are doing it in the IO thread, I would not recommand doing so.
You are also using a Single wich can emit, only one value, or an error. Since you want to return a List, I would sugest to go for at least an Observable.
Third point, the result from Cassandra is paginated, I don't know if it's intentionnaly but you list only the first page, and miss the others.
I would try a solution like the one below, I kept using the IO thread (the operation may be costly in IO) and I iterate over the pages Cassandra fetch :
/* the main method of your controller */
#Get()
public Observable<Person> listPersons() {
return next(personDAO.getAll()).subscribeOn(Schedulers.io());
}
private Observable<Person> next(CompletionStage<MappedAsyncPagingIterable<Person>> pageStage) {
return Single.fromFuture(pageStage.toCompletableFuture())
.flatMapObservable(personsPage -> {
var o = Observable.fromIterable(personsPage.currentPage());
if (!personsPage.hasMorePages()) {
return o;
}
return o.concatWith(next(personsPage.fetchNextPage()));
});
}
If you ever plan to use reactor instead of RxJava, then you can give cassandra-java-driver-reactive-mapper a try.
The syntax is fairly simple and works in compile-time only.

Kotlin Concurrency: Any standard function to run code in a Lock?

I've been searching for a function that takes an object of type Lock
and runs a block of code with that lock taking care of locking and also unlocking.
I'd implement it as follows:
fun <T : Lock> T.runLocked(block: () -> Unit) {
lock()
try {
block()
} finally {
unlock()
}
}
Used like this:
val l = ReentrantLock()
l.runLocked {
println(l.isLocked)
}
println(l.isLocked)
//true
//false
Anything available like this? I could only find the synchronized function which cannot be used like this.
You are looking for withLock, which has the exact implementation you've written yourself, except it has a generic parameter for the result of the block instead of the receiver type.
You can find other concurrency related methods of the standard library here, in the kotlin.concurrent package.

How do I improve this object design in Typescript?

I have created a class in Typescript that implements a simple stream (FRP). Now I want to extend it with client side functionality (streams of events). To illustrate my problem, here is some pseudo-code:
class Stream<T> {
map<U>(f: (value: T) => U): Stream<U> {
// Creates a new Stream instance that maps the values.
}
// Quite a few other functions that return new instances.
}
This class can be used both on the server and on the client. For the client side, I created a class that extends this one:
class ClientStream<T> extends Stream<T> {
watch(events: string, selector: string): Stream<Event> {
// Creates a new ClientStream instance
}
}
Now the ClientStream class knows about map but the Stream class doesn't know about watch. To circumvent this, functions call a factory method.
protected create<U>(.....): Stream<U> {
return new Stream<U>(.....)
}
The ClientStream class overrides this function to return ClientStream instances. However, the compiler complains that ClientStream.map returns a Stream, not a ClientStream. That can be 'solved' using a cast, but besides being ugly it prevents chaining.
Example code that exhibits this problem:
class Stream {
protected create(): Stream {
return new Stream()
}
map() {
return this.create()
}
}
class ClientStream extends Stream {
protected create(): ClientStream {
return new ClientStream()
}
watch() {
return this.create()
}
}
let s = new ClientStream().map().watch()
This does not compile because according to the compiler, the stream returned from map is not a ClientStream: error TS2339: Property 'watch' does not exist on type 'Stream'.
I don't really like this pattern, but I have no other solution that is more elegant. Things I've thought about:
Use composition (decorator). Not really an option given the number of methods I would have to proxy through. And I want to be able to add methods to Stream later without having to worry about ClientStream.
Mix Stream into ClientStream. More or less the same problem, ClientStream has to know the signatures of the functions that are going to be mixed in (or not? Please tell).
Merge these classes into one. This is a last resort, the watch function has no business being on the server.
Do you have a better (more elegant) solution? If you have an idea that gets closer to a more functional style, I'd be happy to hear about it. Thanks!
What you're trying to do is called F-bounded polymorphism.
In TypeScript this is done via the this keyword. Take a look at Typescript's documentation for polymorphic this types. If you follow the documentation, you should be able to implement what you want :-)
Actually, just make sure that you're returning this in your member methods and you should be fine!

Workaround for lack of generators/yield keyword in Groovy

Wondering if there is a way I can use sql.eachRow like a generator, to use it in a DSL context where a Collection or Iterator is expected. The use case I'm trying to go for is streaming JSON generation - what I'm trying to do is something like:
def generator = { sql.eachRow { yield it } }
jsonBuilder.root {
status "OK"
rows generator()
}
You would need continuation support (or similiar) for this to work to some extend. Groovy does not have continuations, the JVM also not. Normally continuation passing style works, but then the method eachRow would have to support that, which it of course does not. So the only way I see is a makeshift solution using threads or something like that. So maybe something like that would work for you:
def sync = new java.util.concurrent.SynchronousQueue()
Thread.start { sql.eachRow { sync.put(it) } }
jsonBuilder.root {
status "OK"
rows sync.take()
}
I am not stating, that this is a good solution, just a random consumer-producer-work-around for your problem.

Groovy, "try-with-resources" construction alternative

I'm a new to Groovy. I used to use 'try-with-resources' construction in my Java code during work with I/O streams.
Could you please advise, is there any analogue of such construction in Groovy?
Groovy 2.3 also has withCloseable which will work on anything that implements Closeable
Groovy 3 newsflash
And Groovy 3+ supports try..with..resources as Java does
https://groovy-lang.org/releasenotes/groovy-3.0.html#_arm_try_with_resources
Have a look at the docs on Groovy IO and the associated javadoc.
It presents the withStream, withWriter, withReader constructions which are means of getting streams with auto-closeability
Simplest try-with-resources for all Groovy versions is the following (even works with AutoCloseable interface). Where class Thing is a closeable class or implements AutoCloseable.
new Thing().with { res ->
try {
// do stuff with res here
} finally {
res.close()
}
}
Which is the equivalent in later versions of Groovy doing:
new Thing().withCloseable { res ->
// do stuff with res here
}

Resources