IO monad

[fwbrasil]

Similar to Slick's DBIO. It should be possible to use it with any of the Source implementations.

[lvicentesanchez]

DBIO is an abstraction that sits between the Querys and the "DB runner". I get that they buy you extra composability by allowing you to sequence queries and also define transactional blocks.

How this would be translated to Quill? Sources run quoted Querys to produce a QueryResult (the query result is defined by the type of Source, e.g Id[List[A]], Future[List[A]] or a Stream[A]).

If you add parametrised quotations to this, where that IO monad would sit? I guess it would have an impact on the AST.... new AST elements to represent parametrised quotations with their argument but that haven't yet run?

I don't know if this make sense :/ so let's use and example. I have this two Cassandra queries (I'm using Cassandra because you are more constraint as you can't join column families):

val getByName = quoted((name: String) => query[User].filter(_.name == name))

val getByID = quoted((id: String) => query[Books].filter(_.id == id))

If we wanted to combine those queries to get all books for a given user, we would have to combine them by running the first one using one of the Source#run methods, and then flatMap the output collection/stream and run the second query for each of the elements.

What you want to add is an IO that would allow us to compose those queries using a simple for comprehension and the use Source#run to run the composed action? If the answer is yes, then I agree it should be part of a 1.0 release :)

[fwbrasil]

@lvicentesanchez This is more or less what I have in mind:

val getByName = quoted((name: String) => query[User].filter(_.name == name))
val getByID = quoted((id: String) => query[Books].filter(_.id == id))

val io = IO(db)

for {
  user <- io.run(getByName)("John").map(_.head)
  books <- io.run(getById)(user.id)
} yield {
  books
}

IO would be like a source adapter.

wdyt?

[lvicentesanchez]

Yes, that's more or less what I had in mind, I will probably called it a source transformer. Would the return type of the for-comprehension be a List[Book]/Future[List[Book]] or a wrapper type similar to scalaz IO/Task that only evaluates the result when run?

[fwbrasil]

Yes, IO will be a free monad:

val getByName = quoted((name: String) => query[User].filter(_.name == name))
val getByID = quoted((id: String) => query[Books].filter(_.id == id))

val io = IO(db)

val res: IO[List[Book]]
  for {
    user <- io.run(getByName)("John").map(_.head)
    books <- io.run(getById)(user.id)
  } yield {
    books
  }

res.run // returns Future, Stream, etc

[jilen]

@fwbrasil Can we have something like res.runTransaction to simplify transaction support

[fwbrasil]

@jilen Yes, run will include transaction support

[gustavoamigo]

Hey, guys, do you really think that this is an essencial feature for version 1.0 release? I was thinking, I am really ok with the current feature set of the snapshot version. Maybe, we should just concentrate on fixing all critical bugs in order to release RC 1.0 as soon as possible? WDYT?

[fwbrasil]

@gustavoamigo makes sense. I'm removing the 1.0 tag, @getquill/maintainers please let us know id you have concerns.

[mdedetrich]

@gustavoamigo

Hey, guys, do you really think that this is an essencial feature for version 1.0 release? I was thinking, I am really ok with the current feature set of the snapshot version. Maybe, we should just concentrate on fixing all critical bugs in order to release RC 1.0 as soon as possible? WDYT?

I think for certain use cases at work its a blocker. We basically need atomic transactions that we can rollback incase something fails (its pretty much a requirement for any serious database work)

Personally I think I am fine with it being delayed, but thats only due to us using stored procedures as a work around. I also have no idea what "delayed" means, are we looking at a year or something?

[fwbrasil]

I think for certain use cases at work its a blocker. We basically need atomic transactions that we can rollback incase something fails (its pretty much a requirement for any serious database work)

The IO monad is not a requirement for providing atomic transactions. You can use db.transaction for that. Am I missing something?

[mdedetrich]

The IO monad is not a requirement for providing atomic transactions. You can use db.transaction for that. Am I missing something?

Does it exist for quill-async? I believe its only available for JDBC. For this reason I also think its a JDBC specific thing (and the queries have to be on the same thread for IIRC), would be better if there was a general solution (regardless of the underlying driver)

[fwbrasil]

@mdedetrich yes, it does :)

[mdedetrich]

Ah, ignore my silliness then!

[fwbrasil]

Ah, ignore my silliness then!

Not your fault at all! It's still undocumented as of the latest release and we're working on improving it. There should be a release candidate soon with the documentation and improvements.

[jilen]

@fwbrasil There's a chance to introduce Source Location tracing using something like source while creating the IO Monad. I think it really helps to find error on production server.