0
votes

I found many examples online that put a call to Database.forConfig inside a trait, and each repository extends this trait. Some examples: https://github.com/BBartosz/akkaRestApi/blob/master/src/main/scala/utils/DatabaseConfig.scala

https://github.com/Platoonhead/SlickWithScala/blob/master/src/main/scala/com/edu/knoldus/connection/ConnectedDbMysql.scala

https://github.com/cdiniz/slick-akka-http/blob/master/src/main/scala/utils/PersistenceModule.scala

Will it lead to creating too many instances of the DB client object, memory overhead, any other performance problems, when having many repositories?

Isn't it better to have one object that will call Database.forConfig and will have a link to the database?

What is the best practice here?

1

1 Answers

0
votes

Here is an example of how I did it:

https://github.com/joesan/plant-simulator/blob/master/app/com/inland24/plantsim/config/AppConfig.scala

So what I basically do is that, I create a single copy of the variable that will call the Slick API and then I specify the number of threads (effectively the number of connections) that I want in the connection pool.

http://slick.lightbend.com/doc/3.0.0/database.html