btw if
F is Sync then you don't need () => F[Unit]. It should be equivalent with F[Unit]
@Avasil bingo, thanks a lot :) Now it's giving unrelated error, which I expected :) neat
regarding () => F[Unit] vs F[Unit] I have have a def task[F[_]: Concurrent](): F[Unit] = ??? that I'm currently intending to pass to the loop. Would it be better to do loop(task()) rather than loop(task), or am I completely missing the point
?
You would need something like this with
Future but fortunately that's not necessary with IO implementations
according to https://typelevel.org/cats-effect/tutorial/tutorial.html#polymorphic-cats-effect-code it's recommended to write effects in terms of
F[_] rather than IO, cool I like that. But I ran in to an issue, mainly how to do this with a Futurefrom an external API? I cannot seem to find any general trait having a fromFuture or similar. How is it best to approach this?
If you are still on 1.x
You have to do the transformation manually :D
It has couple days
dates seems to agree with my assumption :)
anyhow, it seems it's not there, thanks for the response @tzimisce012 :)
it is resolving M4, that explains why fromFuture is missing at least
Don't mix cats.syntax with cats.implicits. I always just choose the latter.
And fromFuture is right. You can't just use Future as F because it's strict and therefore can't have a Sync instance.
is there a point to prefer
def foo[F[_]: Sync[F]]() = ??? over def foo[F[_]]()(implicit F: Sync[F]) I kind of like the flexibility by the implicit setup, but I was wondering because the tutorial use the former version. Am I doing it bad, is it taste, or?
If you have some spare time I wrote about the different approaches and its performance implications @rfftrifork.
(shameless plug 😄)
Hi all, i am writing a simple program that access to db via jdbc but i currently i dont want to use doobie. In my code i prepared a small utility like below. Is it enougn to handle local transactions or is there any edge cases that i miss? Thank you in advance:
implicit class richIODatasource[D <: DataSource, F[_]:Sync](val ids: F[D]) extends AnyVal {
import cats.effect.ExitCase.{Completed, Error, Canceled}
def use[T](f: Connection => F[T]): F[T] =
Resource.fromAutoCloseable[F, Connection](ids.map(_.getConnection())).use(c => f(c))
def transaction[T](f:Connection => F[T]):F[T] = use{ c =>
Sync[F].bracketCase(Sync[F].pure(c).map{c =>
c.setAutoCommit(false)
c
})(f){
case (in, Canceled | Error(_)) =>Sync[F].delay(in.rollback())
case (in,Completed) => Sync[F].delay(in.commit())
}
}
}
@capacman I'm fairly new to effects, but to me it looks correct. I'm wondering though if you'd need a begin transaction call. I seem to recall the ExitCase of bracket is a sealed trait, so I think you'll get a compiler warning if you don't cover all cases possible, but if I remember wrong then you might consider a default case where you do a rollback. Also slightly beside your point, I'll strongly urge you to log errors, including the input that cause them ;)
hmm does anyone have some advice/experience/best practices with how to write better tests with effects? Currently I'm doing mixing of for comprehensions and unsafeRunSync, but it feels kind of awkward, I just cannot see how else to do it, e.g.:
"My app" should "do bar" in {
val barsF = for {
foo <- foo()
bars <- foo.bars()
} yield bars
val bars = barsF.unsafeRunSync
// tests go hereI'm struggling a bit, because in a way the cleanest would be to do the tests as F[_]s too, such that they are just a part of the for comprehension, but in a way it also feels slightly off/awkward to me
If you're using scalatest, it supports tests returning futures as well. Check the Async* styles. I guess it's not too difficult to add utilities for IO or for any F[_]: Effect. There is a lot of chatter about pure FP testing frameworks recently but idk if there is anything ready to be used.
