Scala Async Helpers?

15 views
Skip to first unread message

er...@eluvio.com

unread,
Jul 20, 2016, 4:24:54 PM7/20/16
to jOOQ User Group
I started playing with some async helpers & the scala-compat-java8 library:

I now have async versions of the helper functions now returning a type Future to make everything play nice in Scala: https://gist.github.com/er1c/d548d62091e8d8fce21dd2a9df1c1d65

I'm not sure if these would make sense to include in the current org.jooq.scala.Conversions?  Or, another idea I was toying with, was having two different versions of org.jooq.scala.Conversions, say, org.jooq.scala.async.Conversions, such that, the intended usage would be to have "def fetchOneOption" return an Future[Option[Record]] without having to explicitly call out a separate "fetchOneOptionAsync" call.

I'm not sure if that convenience outweighs the possible complexity, so I'm leaning toward having the explicit names with Async to mark the type of call they are. This is a little "hacked together" since I'm implementing these methods only for scala. Would it make sense to have java-versions of the "fetchAnyAsync/fetchOneAsync/fechValueAsync" for both ResultQuery & DSLContext, then the scala Option wrappers would do just the Option + Future conversions?

LMKYT,

-Eric

er...@eluvio.com

unread,
Jul 21, 2016, 5:37:53 PM7/21/16
to jOOQ User Group, er...@eluvio.com
I started going down this path and in the end, I think I'm going to abandon it for just managing my own TaskRunner/executor and using the blocking calls that are already well supported on the java side.

Lukas Eder

unread,
Jul 22, 2016, 2:25:25 AM7/22/16
to jooq...@googlegroups.com
Thanks a lot for your feedback. It's interesting to see how Scala users would integrate asynchronous jOOQ usage into the Scala ecosystem. Java 8 introduced CompletionStages (and the less fortunate CompletableFuture). Personally, I'm not 100% convinced that these APIs will be very well adopted, even if they're the new standard. If you are able to integrate with state-of-the-art Scala libraries for asynchronicity, that path might certainly be preferable.

Having said so, I'm currently not a big fan of adding too many combinatorially explosive API methods of the form fetchOneOptionAsync (where "One", "Option", and "Async" are three different parameters to "fetch", and more might come). I.e. before more "Async" API is added, I'd like to learn about the adoption of the existing jOOQ 3.8 Async methods.

Lukas

--
You received this message because you are subscribed to the Google Groups "jOOQ User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jooq-user+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply all
Reply to author
Forward
0 new messages