From what I've read in the Play documentation, this is intentional. [0] They say:

> SQL is already the best DSL for accessing relational databases.

I have no real opinion on the matter, as someone who doesn't like working with databases very much, I appreciate the comfort a ORM mapper gives me, but so far, all my web apps have been very small and basically trivial, so I don't know how they work with bigger projects.

[0]: http://www.playframework.com/documentation/2.2.x/ScalaAnorm

I don't find working the SQL in Scala to be very much fun. You end up having to write lots of marshaling functions and other such cruft that isn't application logic. As someone used to dynamic languages this makes the code very ugly and verbose.

I've just recently discovered Slick only by noticing it performed quite well in TechEmpower's last round of benchmarks. So I'm genuinely curious, what's wrong with Slick?

I recently learned Slick, and it was a hellish ride. First of all, a large part of the problems I had were an unbelievable terrible documentation. Sometimes, in order to do even the simplest things, I had to look into particular unit tests deep within the sources of the project, or follow stackoverflow discussions with multiple proposals, only one of which actually worked. Oftentimes this was for things which I considered granted and implemented. The certainly best example is getting an object by id. I would have thought that this, being the most basic operation, should be possible through some kind of default operation like "get" or "getById" or "objectById" or something else. Instead, you have stackoverflow answers like this:

def findById(userId: Int)(implicit session: Session): Option[User] = { val query = for{ u <- Users if u.id === userId } yield u query.firstOption }

http://stackoverflow.com/questions/16461260/select-single-ro...

However, that's not even the brink of the iceberg. Try finding out how to update multiple fields in an object. Say you retrieve a User object, and you want to set a new email, zip, and address. I'd suppose, this would work with simple getters and setters, i.e.:

user = Users.get(user_id) user.email = new_mail user.zip = new_zip user.address = new_address

Instead, you have to do this:

val map = Query(User) .filter(_.id === user_id) .map(ab => ab.email ~ ab.zip ~ ab.address)

map.update((new_mail, new_zip, new_address))

And even that only works with updateable result sets. See: http://stackoverflow.com/questions/16757368/how-do-you-updat...

https://groups.google.com/forum/#!msg/scalaquery/ML56aZAfy3g...

Or, to quote from the stackoverflow answer above: "Typesafe, why your documentation is so bad ? I have to Google pretty much every silly thing or dig through unit-tests for hours. Please improve it. Thanks."

Now, after a lot of searching, I found solutions to all of my problems, but it took a long time, lots of Google, and almost nothing came out of their awful documentation.

This. Slick might be the one true way that typesafe and other purveyors of Scala might believe we should be using to interacting with the database. But not all of us can start there. We'd like a simple ORM that can provide some abstractions and facilities (auto-generated findBy, relational mapping). Finally we went with scala-activerecord which seems to have hit the sweet spot between providing just enough functionality to be an ORM but not blowing up to be a complex beast with secret incantations (ala Hibernate).

All the derision that Rod Johnson got for his keynote where he mentioned the lack of ORM (among other things) as being intimidating to a beginner seems unfair.

This looks great. Seriously all of the answers you give seem simple and convenient ways of doing things.

You could reduce your first example to def findById(userId: Int)(implicit s: Session) = Users.filter(_.id === userId).firstOption

Certainly true, but when you're just starting out, that kind of thinking may not be there yet. You need some time with Slick to understand this, and it is difficult to get into it because it lacks the simple facilities. I actually spend a lot of time searching for these simple facitilies until I realized that they're really not there yet.

It's a lot of ceremony for not a lot of convenience.

See: http://slick.typesafe.com/doc/1.0.1/lifted-embedding.html#in... and notice how much is involved in doing a simple insert into a table with a primary key.

  Users.forInsert insert User(None, "Christopher", "Vogt")

Personally, I don't find that to be a lot of ceremony. Now, Slick definitely still has some problems and requires too much boilerplate, I'll certainly agree with that but I don't think this is one of those cases (though it could be improved).

THe ceremony is creating the "for insert" facade. To me the logical thing to do would be for Slick to have an "AutoInc Int/Long" type that is implicitly convertable from Option, so that you could just do a normal insert and the the None value just causes the id column to be omitted.

It also supports raw SQL...

That goes beyond what it was created for. If you need sql to do anything useful, you can just as well not use a ORM.

Slick generates some pretty bad SQL with deep nested select statements for some pretty typical join queries. That alone was a deal breaker for me. It also doesn't help that Typesafe has been fairly quiet regarding the future of Slick as of late.

I quite liked the look of EBean, though I haven't really used it much. Even so, it's fairly easy to plug in a JPA manager (in my case, Hibernate) and use the helper classes provided for DB management.

Edit: should add that I'm mainly familiar with the Java play framework aspects, not so much the Scala end.

I have been very happy with MyBatis in Java projects and will use its scala version if I start on a Play framework project.

jdbc is real good