3 ms·

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 w

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?

TylerE 13y ago
It's a lot of ceremony for not a lot of convenience. See: http://slick.typesafe.com/doc/1.0.1/lifted-embedding.html#inserting 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.
- trailfox 13y ago
  It also supports raw SQL...
  - terhechte 13y ago
    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.
- saryant 13y ago
  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).
  - TylerE 13y ago
    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.
terhechte 13y ago
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-row-based-on-id-in-slick 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-update-multiple-columns-using-slick-lifted-embedding http://stackoverflow.com/questions/16757368/how-do-you-updat... https://groups.google.com/forum/#!msg/scalaquery/ML56aZAfy3g/nx-PPV1y2dEJ 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.
- krishy 13y ago
  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.
asdf1234 13y ago
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'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?

TylerE 13y ago

It's a lot of ceremony for not a lot of convenience. See: http://slick.typesafe.com/doc/1.0.1/lifted-embedding.html#inserting 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.

trailfox 13y ago
It also supports raw SQL...
- terhechte 13y ago
  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.
saryant 13y ago
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).
- TylerE 13y ago
  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.

terhechte 13y ago

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-row-based-on-id-in-slick 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-update-multiple-columns-using-slick-lifted-embedding http://stackoverflow.com/questions/16757368/how-do-you-updat... https://groups.google.com/forum/#!msg/scalaquery/ML56aZAfy3g/nx-PPV1y2dEJ 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.

krishy 13y ago
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.

asdf1234 13y ago

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.