0

Suppose I have such schema (simplified), using slick 2.1:

// Banks
case class Bank(id: Int, name: String)

class Banks(tag: Tag) extends Table[Bank](tag, "banks") {
  def id = column[Int]("id", O.PrimaryKey)
  def name = column[String]("name")

  def * = (id, name) <> (Bank.tupled, Bank.unapply)
}

lazy val banks = TableQuery[Banks]

Each bank has, say, 1:1 BankInfo, which I keep in separate table:

// Bank Info
case class BankInfo(bank_id: Int, ...)

class BankInfos(tag: Tag) extends Table[BankInfo](tag, "bank_infos") {
  def bankId = column[Int]("bank_id", O.PrimaryKey)
  ...
}

lazy val bankInfos = TableQuery[BankInfos]

And each bank has associated 1:M BankItems:

// Bank Item
case class BankItem(id: Int, bank_id: Int, ...)

class BankItems(tag: Tag) extends Table[BankItem](tag, "bank_items") {
  def id = column[Int]("id", O.PrimaryKey)
  def bankId = column[Int]("bank_id")
  ...
}

lazy val bankItems = TableQuery[BankItems]

So, if I used ORM, I would have had convenient accessors for associated data, something like bank.info or bank.items. I've read "Migrating from ORMs", and I understand that Slick doesn't support full relation mapping, though I've seen example where foreignKey was used.

Basically, where should I place my code to access related data (I want to access all BankItems for some Bank, and its BankInfo). Should it be implemented in case classes, or in Table classes, or elsewhere? Can someone give me a practical advice on what is a "standard practice" in this case?

dmitry
  • 4,989
  • 5
  • 48
  • 72
  • Take a look https://github.com/satendrakumar06/slick-for-production This has been written in slick 3.0.1. I would recommend use Slick 3.0.1 instead of 2.1.0 if you going to start. – Sky Aug 16 '15 at 13:20
  • @Sky Thanks, though it looks overcomplicated for such a basic task. – dmitry Aug 17 '15 at 08:34
  • @dimtry Yes, you are right. Because all database access methods are independent from database so you can change database according to environment or you need.For eg: H2 for unit testing and MySql for production. If you like unit testing then It may be helpful . – Sky Aug 17 '15 at 15:17

0 Answers0