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.
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 to be best for my purposes at the time.
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.
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/
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.
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.
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.
That's OK, but I would still like to do it the other way. Where the code is generated from the DB. Might just be my mindset but I prefer to work in the DB tool and then layer the application on top.
This will be one of the big topics for us for the next months. We are planning to add type macros to Scala (in addition to the def macros that are already available as an experimental feature in the 2.10 milestones) and use them to generate types representing database schemas directly from the database. The idea is to have the compiler connect to a live database during development and a way to freeze the generated types at some point in the form of standalone Scala source which does not need a database any more for compilation.
>> 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.
With pleasure. You are wrong. SLICK (formerly known as ScalaQuery) is Typesafe.
>> I am working with Play! at the moment and while the DB access is the best I have come across in the Java world
I've been working with Scalaquery with Play 2 for two months now. The experience has been fantastic. I haven't really had any queries I haven't been able to create even complex joins.
The approach where queries are made like Scala collections is really intuitive. Compared to you I just started using linq recently for a work related project. Basically coming from the other end and I've been quite pleased that the SQ skills I've built over the past month transferred over reasonably well. I only have good things to say about Slick. You should try it out.
Its only typesafe if you generate against the database though correct? Its entirely possible for me to write it by hand, and not know there is a problem till runtime yes? I want to close this loop, and LINQ is the only db access I have tried that does so.
Should have mentioned I am using Scala for the DB access in Play 2.0 and the other portions are mostly Java (heavy lifting done in existing libraries, so its just plumbing work hence doing it in Java). I am pretty happy with it except I still hit type issues which I would never encounter in LINQ.
I guess the way im looking at it is that LINQ solved a pain point for me which I am still experiencing in other languages. I would very much like someone to take the pain away from me, either by getting C# working well on Linux or bringing some of the features from C# over into the Java world.
I absolutely agree that LINQ has no peer in the open source world. I too am a .NET/C# dev by day but I've been playing around a lot with the Play! framework on my own time (built the UI to my senior thesis in it) and I much prefer their ANORM over a bastardized ORM that only half-works.
16 comments
[ 3.4 ms ] story [ 44.5 ms ] threadI 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.
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.
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.
With pleasure. You are wrong. SLICK (formerly known as ScalaQuery) is Typesafe.
>> I am working with Play! at the moment and while the DB access is the best I have come across in the Java world
I've been working with Scalaquery with Play 2 for two months now. The experience has been fantastic. I haven't really had any queries I haven't been able to create even complex joins.
The approach where queries are made like Scala collections is really intuitive. Compared to you I just started using linq recently for a work related project. Basically coming from the other end and I've been quite pleased that the SQ skills I've built over the past month transferred over reasonably well. I only have good things to say about Slick. You should try it out.
Should have mentioned I am using Scala for the DB access in Play 2.0 and the other portions are mostly Java (heavy lifting done in existing libraries, so its just plumbing work hence doing it in Java). I am pretty happy with it except I still hit type issues which I would never encounter in LINQ.
I guess the way im looking at it is that LINQ solved a pain point for me which I am still experiencing in other languages. I would very much like someone to take the pain away from me, either by getting C# working well on Linux or bringing some of the features from C# over into the Java world.
I absolutely agree that LINQ has no peer in the open source world. I too am a .NET/C# dev by day but I've been playing around a lot with the Play! framework on my own time (built the UI to my senior thesis in it) and I much prefer their ANORM over a bastardized ORM that only half-works.