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 2016-07-21 23:37 GMT+02:00 <[email protected]>: > 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. > > > On Wednesday, July 20, 2016 at 1:24:54 PM UTC-7, [email protected] wrote: >> >> 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 >> > -- > 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 [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
