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.
