Creation of session should return `F[Session[F]]`

Creation of mutable state should be wrapped in F for the reasons stated here and here. Fabio Labella also gave a great talk on the topic.

val session: Session[IO] = driver.session().asScala[IO] // this can leak

val makeSession: IO[Session[IO]] = driver.session.asScala[IO] // this is the action of creating a session

makeSession.flatMap { s => // here we create a region of sharinn
  useSession(s) // whoever needs access to the session should take it as a parameter 
 // in this way the sharing of the session is under our control in a narrow scope (inside `flatMap`)
}

Right now I get around by just wrapping its creation in IO but ideally the library should do this.

This probably doesn’t make sense when using Future since it breaks referential transparency but for the rest of us using FP libraries this is important.

Let me know if I can be of any help.

[BalmungSan]

I think some kind of Resource typeclass from our side may work. Since it seems the only area of friction is really just the Driver / Session creation and lifecycle management. For the rest of the code, it seems both worlds can coexist without problems.

Maybe something like:

trait Resource[F[_]] {
  type R[_, _] // I think I have a syntax error here, since the first parameter should be like F[_].

  def create[T](t: => T): R[F, T]
}

Where for IO R[_, _] == Resource[IO, T] and for Future R[_, _] = Id[Id, T] Thus Future users could do this:

val driver: Driver[Future] = GraphDatabase[Future].driver(...)
val session: Session[Future] = driver.session(...)

While IO (and friend) users will have:

val session: Resource[IO, Session[IO]] = for {
  driver <- GraphDatabase[IO].driver(...)
  session <- driver.session(...)
} yield session

(For Zio folks it will be a ZManaged instead).

This is just an sketch I just made on top of my head, I am not totally sure if both cases can be supported as seamlessly as we want. But I do think it is worth exploring!

[gvolpe]

No worries. The concept of mutable state sharing is so simple that is hard to get at first 😃

In the first example (the one that leaks a session) we could potentially have unintended access to our session. This compares pretty much to global state. The variable s can be accessed anywhere in Main but it could also be accessed from anywhere in the program by doing Main.s (yes, you could restrict this by adding private but the first problem remains).

In the second (and safe) example we are making explicit when some mutable state is being created as we don’t want to unintentionally share it. So it is wrapped in IO (or any other arbitrary effect). If we call mkSession is obvious that we are creating a new session, you only need to look at its type signature. And if we want to share this session then you need to create an explicit region of sharing which is dictated by flatMap and pass it as an argument.

Again, I recommend watching Fabio’s talk, he does a great job explaining this.