Driver
Driver

Reputation: 548

How to think Slick?

I'm struggling a bit in Slick and i'm a recent Scala/Slick adopter. I'm used to Hibernate and/or Rails ActiveRecord but i'm having a bit difficulty joining plenty of tables.

I have the Following class pattern.

case class User(id: UUID, ..., profile: UserProfile)
case class UserProfile(id: UUID, ..., address: Address)
case class Address(id: UUID, ...)

I'm trying to have this as a Domain Model and having the Persistence Layer just fetch and join the tables to return a domain single object.

  1. Is is the right way to do it in slick?
  2. Is there anyway to cache the Query Results instead of being constantly querying the database?
  3. Does this Lib help?
  4. What's the best way of joining for example these 3 tables? 1 Query to each of them via separate DAO's or Inner Joins and use Scala's groupBy ?

Sorry if this is a "newbish" question. I'm just trying to figure out how to "Think Slick".

Upvotes: 2

Views: 443

Answers (2)

insan-e
insan-e

Reputation: 3921

  1. There is no right way of doing it. It depends on what you need to do with your model... There is right way of modelling relational database model, but you already know that.
  2. Slick doesn't use any caches, see here. But if you use Play Framework for example, it provides CacheApi, but I have no experience or advice for that. But, for queries you can have some "caching", like compiled queries.
  3. Probably yes, for simple cases, simple tables etc. But you could also use Hibernate for that, which is far more older and reliable.
  4. I was stuck with it also when I was a Scala/Slick beginner, so I wrote a blog about that(It's on Slick's 3rd party docs also, yes I'm bragging :p). There is also a simple companion project for it.

Understanding plain SQL, it's joins etc helps a lot when using Slick. For example, does the outer join(left/right) order matter, and other interesting questions.

Upvotes: 2

pedrorijo91
pedrorijo91

Reputation: 7845

I wrote a small tutorial on play + slick some time ago. check it and see if it helps http://pedrorijo.com/blog/play-slick/

I usually have:

case class CaseClassA(field1, field2, caseClassB_Id)
case class CaseClassB(field3, field4)

but maybe there's a better approach

Upvotes: 0

Related Questions