Async wrappers for JdbcContext

[povder]

It would be really cool to be able to use asynchronous interface (queries returning Futures) for databases that don't enjoy having any Scala/JVM asynchronous driver.

It could be achieved by AsyncContext implementation using quill-jdbc underneath, basically wrapping JdbcContext (I'm not very familiar with the codebase so I may be wrong about this).

Benefits:

• after https://github.com/getquill/quill/issues/379 has been implemented, H2 in-memory database could be used in development environment, and for example PostgreSQL in production using the same interface, which is kind of a standard setup.
• we can hope that there will be more async drivers implemented in the future. Developers could target databases without async drivers using async wrapper with some thread pool for now, and then seamlessly change to real asynchrony without the need to rewrite blocking code to non-blocking one.

@getquill/maintainers

[povder]

Actually I'm having second thoughts about this, I think this shouldn't be impemented in quill but rather in mauricio/postgresql-async. See https://github.com/mauricio/postgresql-async/issues/188

[schmitch]

@fwbrasil btw. I think this is a good idea when we include the following in the quoting of the Macro:

val ec = implicitly[ExecutionContext]
Future { 
// Old macro stuff
}

And then a true / false if the Macro will have the Future around. I guess without adding it to the macro it's really hard. After that we can have a AsyncJdbcContext and a JdbcContext.

The good part is, that after we've done that, is that AsnyJdbcContext is easily replaceable with the async counterparts. Especially when you create a wrapper for your context like that:

class MyContext(dataSource: DataSource with Closeable)(implicit ec: ExecutionContext) extends JdbcContext[PostgresqlDialect, SnakeCase]

[fwbrasil]

Closed in favor of https://github.com/getquill/quill/issues/1180

[deusaquilus]

Wait a minute, #1180 is for embedded databases, not NDBC in general let’s at least link this correctly. I think we should reopen this because even if we have NDBC modules it won’t cover all of the currently supported JDBC databases. Check out this great work by @oleg-py https://github.com/oleg-py/quill-monix

On Mon, Dec 3, 2018 at 2:45 PM Flavio W. Brasil notifications@github.com wrote:

Closed in favor of #1180 https://github.com/getquill/quill/issues/1180

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/getquill/quill/issues/474#issuecomment-443822221, or mute the thread https://github.com/notifications/unsubscribe-auth/ABTliBBo01LT0drSdpQ8O2KIHLloY_p6ks5u1XFTgaJpZM4JUX98 .