io free monad

[fwbrasil]

Fixes #21

Problem

Quill performs side effects but doesn't provide an easy way to isolate them.

Solution

Introduce the IO free monad that defers execution until unsafePerformIO is called.

Notes

The execution of IO uses the same execution mechanism as its context. For instance, it doesn't try to implement an async wrapper on top of jdbc; the return type of a synchronous context is synchronous.

Checklist

• Unit test all changes
• Update README.md if applicable
• Add [WIP] to the pull request title if it's work in progress
• Squash commits that aren't meaningful changes
• Run sbt scalariformFormat test:scalariformFormat to make sure that the source files are formatted

@getquill/maintainers

[fwbrasil]

@getquill/maintainers this is ready for review. The readme has more information.

@missingfaktor I'd love to hear your thoughts on this if you have some time to spare.

[mosyp]

Great work!
However it seems like you need context instance to create io task and then execute them using those contexts, right? Hence particular io task is bound to context.
Is it possible to separate this? Something like this:

val task = io(query[Person].insert(lift(p))).flatMap { _ =>
   io(query[Person])
}
ctx.run(io)

Where ctx could be any of supported, future, twitter future, raw sync etc., and io is a free monad

[mosyp]

I was talking about something like this

val sql = new SqlDialect[SnakeCase] // It could be even static since it is stateless
val io = sql.run(query[Person])
  .filter(_.age > 10)
  .flatMap(p => sql.run(query[Person].delete(lift(p))))

val asyncCtx = new AsyncPostgresContext
val syncCtx = new SyncMySqlContext

asyncCtx.run(io) // res1: Future[Unit]
syncCtx.run(io) // res2: Unit

So we have 2 separate layers, free monad for query generation and second one for actual execution

[fwbrasil]

@mentegy thanks for the feedback. That's a good point, but there are more complexities to it. We made the decision of making everything dependent on the context some time ago (#417). I think we could revisit this decision before 2.0, but it's definitely something that shouldn't be in the scope of this change given the complexity. Could you open a new issue with your proposal so we can discuss in detail?

[mosyp]

@fwbrasil I got this, description of #21 confused me a little bit. Everything else looks great for me except unsafePerformIO naming. I think that performIO is enough or something like this, hence, it's actually safe (for futures at least, depends on context) and there's no alternative such as safePerformIO

[fwbrasil]

@mentegy the "unsafe" part is a convention to indicate that the method performs side effects. I agree that it can be confusing. I'll rename it.

[jilen]

Will this leads postgres-async and mysql-async to run multi query at the same time on same connection ?

[fwbrasil]

@jilen yes. Do you ask that because of the concurrency issue with parallel queries under a transaction? I think that's a driver bug. For instance, ndbc handles this scenario without problems.

[jilen]

@fwbrasil Yes. And if it not support sequence we could point it out somewhere.

[fwbrasil]

@jilen I think that's a separate issue. The same happens with Future.sequence. Could you make sure that we have an issue open for it? If the driver doesn't fix it, we can workaround on the quill side by having a synchronization point for transactions.

[jilen]

@fwbrasil I'll open an issue while this pr merged

[fwbrasil]

@mentegy unsafePerformIO renamed to performIO

[mosyp]

LGTM!