Idiom - what to return from Dao/Repository

[yatesco]

Hi there - huge newbie warning.

What do people generally return from the traits that represent the data access layer? Returning doobie.Query0[MyType] allows the check(traitFn) to work, but isn't returning IO, which feels unidiomatic.

Having the trait return something like ConnectionIO[List[MyType]] feels more idiomatic but then the check doesn't work in the tests because it cannot find an implicit evidence for that parameter.

What's the idioms/styles/best practice here?

Thanks!

[m-tabaza]

Hey @yatesco

One option is to return ConnectionIO from the functions in the database access trait, since ConnectionIOs can be combined into one ConnectionIO (using .flatMap or a for comprehension) that runs multiple operations on the database on the same connection (or even the same transaction). After combining your ConnectionIOs, it's easy to later turn them into an IO using .transact.

Another option (the one I prefer) is to have the data access trait be parameterized with F[_], and return Fs from all functions. This F could later, for example, be fixed to ConnectionIO in an implementation of the trait.

The functions returning Query or Update could be kept in an object or a package separately, since a Query0 can be used in multiple ways by different functions. For example, given the trait and implementation:

// UserAlgebra.scala
trait UserAlgebra[F[_]] {
  def getUser(userId: Long): F[User]
  
  def getUserIfExists(userId: Long): F[Option[User]]
}

// UserRepo.scala
object UserRepo extends UserAlgebra[ConnectionIO] {
  def getUser(userId: Long): ConnectionIO[User] = 
    selectUserById(userId).unique
  
  def getUserIfExists(userId: Long): ConnectionIO[Option[User]] = 
    selectUserById(userId).option
    
  def selectUserById(id: Long): Query0[User] = 
    sql"SELECT * FROM users WHERE id = $id".query
}

Notice how the query returned from UserRepo.selectUserById is used twice in different ways to return a ConnectionIO. This approach enables you to:

• Reuse queries to a certain extent by using different methods of Query0 for different use cases (e.g. .unique, .option, .nel, .to[List], .stream, etc)
• Check your queries in tests (e.g. check(UserRepo.selectUserById(1)))
• Create test instances of UserAlgebra that do not talk to the database at all (i.e. by fixing F to IO or any other effect type)
• Combine UserRepo functions more efficiently and running multiple functions in the same transaction

I hope this helps :)

[yatesco]

thanks - this was excellent.