4 ms·

Slick: a modern database query and access library for Scala

53 points by LiveTheDream 14y ago

agentcoops 14y ago
Glad to see a standard Scala DB solution emerge---especially one backed by Typesafe. I really found the lack of an elegant database solutions in Scala to be a huge setback in heavy Scala use a year ago. Excited to give it a try.
- factorialboy 14y ago
  Squeryl http://squeryl.org/ http://squeryl.org/ has been around a while!
  - agentcoops 14y ago
    Yes, there were lots of solutions a while back, including Slick's predecessor ScalaQuery, but none of them were that developed and it required you to build a fresh object model from whatever legacy schema you had. Not difficult to automate, but with so many solutions and it being entirely unclear which would survive, it was difficult to justify even that minimal effort of converting and testing. In the end, I found a modified version of https://wiki.scala-lang.org/display/SYGN/Simplifying-jdbc https://wiki.scala-lang.org/display/SYGN/Simplifying-jdbc to be best for my purposes at the time.
boyter 14y ago
The problem I can see is that its not totally type safe as you still need to run the code to check that your entity is compatible with the underlying table at runtime. If I am wrong here please correct me. It appears fairly easy to make a mistake on the datatype (Int vs Long) and have it blow up in your face when you run it. Sure the re-factoring is simple but I don't want to wait till runtime to catch these issues. I don't think that its not achievable either. I think that LINQtoSQL and EntityFramework are the best implementation of database access that exists today. Import the database/table select over it with 95% assurance that the query will work at runtime and with the correct types. I really wish something like this existed in the Java world as I would switch in a heartbeat. For the record I code C# mostly in my day job, but every time I move over to PHP/Java/Scala I miss LINQ. I am working with Play! at the moment and while the DB access is the best I have come across in the Java world, its still not at the same standard. I am still getting issues with simple selects where I should be using a Long rather then an Int.
- wheaties 14y ago
  Yes and no. I'm building a library that allows you to at least pull in the database structure and have the code auto-generated so that your code agrees with the schema. You can see it here: http://wheaties.github.com/Squealer/ http://wheaties.github.com/Squealer/ After that, if your production schema is that different from your development schema that auto-generated code can't help, then you've got more problems than that.
  - boyter 14y ago
    Looks good. I know that issues where the schema is different are always going to be a problem (nothing can save you there unless you want auto generated entities every time) but I can live with that. How are you dealing with issues like the one I found the other day. A view was created in MySQL which selected from a table with a column compressed with the compress function and was uncompressed in the view. IE select id,uncompress(content) as content from stuff; The above looks fine, but unless you cast the content to a char most ORM's have issues working out what it is, yet it looks fine in your standard mysql command line query. It's an unusual case, but I would like to see the autogenerated code produce a binary cast so I can explicitly see the error when I generate rather then at runtime.
    - wheaties 14y ago
      That, unforunately, I can't help with. Like any SQL DSL I've worked with, there's a few features that still aren't fleshed out... yet. I have complete faith they will flesh them out if prompted by the community. After that, you'll have to use pure SQL and cross your fingers.
      - boyter 14y ago
        Oh well. If its decent enough I can live with this single issue as I catch it pretty easily though integration tests.
- jzoidberg 14y ago
  It looks like the DB schema is generated from the class definitions by the library. Queries are type safe: http://slick.typesafe.com/doc/0.11.0/gettingstarted.html#schema http://slick.typesafe.com/doc/0.11.0/gettingstarted.html#sch...
factorialboy 14y ago
To me it looks inspired by Squeryl http://squeryl.org/ http://squeryl.org/
- LiveTheDream 14y ago
  It's actually based on ScalaQuery (http://scalaquery.org/ http://scalaquery.org/).

53 points by LiveTheDream 14y ago

Glad to see a standard Scala DB solution emerge---especially one backed by Typesafe. I really found the lack of an elegant database solutions in Scala to be a huge setback in heavy Scala use a year ago. Excited to give it a try.

factorialboy 14y ago
Squeryl http://squeryl.org/ http://squeryl.org/ has been around a while!
- agentcoops 14y ago
  Yes, there were lots of solutions a while back, including Slick's predecessor ScalaQuery, but none of them were that developed and it required you to build a fresh object model from whatever legacy schema you had. Not difficult to automate, but with so many solutions and it being entirely unclear which would survive, it was difficult to justify even that minimal effort of converting and testing. In the end, I found a modified version of https://wiki.scala-lang.org/display/SYGN/Simplifying-jdbc https://wiki.scala-lang.org/display/SYGN/Simplifying-jdbc to be best for my purposes at the time.

boyter 14y ago

The problem I can see is that its not totally type safe as you still need to run the code to check that your entity is compatible with the underlying table at runtime. If I am wrong here please correct me. It appears fairly easy to make a mistake on the datatype (Int vs Long) and have it blow up in your face when you run it. Sure the re-factoring is simple but I don't want to wait till runtime to catch these issues. I don't think that its not achievable either. I think that LINQtoSQL and EntityFramework are the best implementation of database access that exists today. Import the database/table select over it with 95% assurance that the query will work at runtime and with the correct types. I really wish something like this existed in the Java world as I would switch in a heartbeat. For the record I code C# mostly in my day job, but every time I move over to PHP/Java/Scala I miss LINQ. I am working with Play! at the moment and while the DB access is the best I have come across in the Java world, its still not at the same standard. I am still getting issues with simple selects where I should be using a Long rather then an Int.

wheaties 14y ago
Yes and no. I'm building a library that allows you to at least pull in the database structure and have the code auto-generated so that your code agrees with the schema. You can see it here: http://wheaties.github.com/Squealer/ http://wheaties.github.com/Squealer/ After that, if your production schema is that different from your development schema that auto-generated code can't help, then you've got more problems than that.
- boyter 14y ago
  Looks good. I know that issues where the schema is different are always going to be a problem (nothing can save you there unless you want auto generated entities every time) but I can live with that. How are you dealing with issues like the one I found the other day. A view was created in MySQL which selected from a table with a column compressed with the compress function and was uncompressed in the view. IE select id,uncompress(content) as content from stuff; The above looks fine, but unless you cast the content to a char most ORM's have issues working out what it is, yet it looks fine in your standard mysql command line query. It's an unusual case, but I would like to see the autogenerated code produce a binary cast so I can explicitly see the error when I generate rather then at runtime.
  - wheaties 14y ago
    That, unforunately, I can't help with. Like any SQL DSL I've worked with, there's a few features that still aren't fleshed out... yet. I have complete faith they will flesh them out if prompted by the community. After that, you'll have to use pure SQL and cross your fingers.
    - boyter 14y ago
      Oh well. If its decent enough I can live with this single issue as I catch it pretty easily though integration tests.
jzoidberg 14y ago
It looks like the DB schema is generated from the class definitions by the library. Queries are type safe: http://slick.typesafe.com/doc/0.11.0/gettingstarted.html#schema http://slick.typesafe.com/doc/0.11.0/gettingstarted.html#sch...

factorialboy 14y ago

To me it looks inspired by Squeryl http://squeryl.org/ http://squeryl.org/

LiveTheDream 14y ago
It's actually based on ScalaQuery (http://scalaquery.org/ http://scalaquery.org/).