A Slicker Typesafe Stack: Q&A with Martin Odersky

Typesafe [1] announced this morning [2] that the Scala Language Integrated Connection Kit [3] (Slick [4]) has been added to its Typesafe Stack [5]. Slick has been mentioned in Michael Azoff [6]'s Typesafe roadmap indicates the maturing of Scala [7] and the ScalaDays 2012 [8] presentation SLICK: Scala Language Integrated Connection Kit [9] provides significant details about Slick [10] as well as code examples of how to use it.

The "About" portion of the Slick web page [3] states the following:

Slick is a modern database query and access library for Scala. It allows you to work with stored data almost as if you were using Scala collections while at the same time giving you full control over when a database access happens and which data is transferred. You can write your database queries in Scala instead of SQL, thus profiting from the static checking, compile-time safety and compositionality of Scala. Slick features an extensible query compiler which can generate code for different backends.

I had the opportunity to pose some questions to Scala [11] creator and Typesafe co-founder [12] Martin Odersky [13] about Slick [3]. It is exciting to think about what Slick offers based on Martin [14]'s answers (posted next) and based on the material available on the Slick website [3] (tweeted by Martin yesterday [15]).

Slick Q&A with Martin Odersky

Q: Is Slick open source?

A: Yes, Slick is an open source project.

Q: What is the licensing for Slick?

A: Slick is distributed under a BSD-style license. The license was chosen to be the same as Scala's to keep the hurdle for adoption low.

Q: Can Slick be used with databases other than those explicitly supported as listed in the press release (such as Oracle)? and Q: What steps must be taken to use a database other than those listed?

A: Yes. The session handling and "plain SQL" layer is database-independent. Compiling Scala code to SQL requires a Slick driver for the target DB. There is a BasicDriver implementation based on standard SQL which should support the majority of standard features of many database systems. Since all databases in practice deviate more or less from the SQL standard, custom driver implementations will be needed to make use of all features.

Q: Is Slick extensible to make use of an unsupported database transparent to the developer if certain extensions are implemented (in other words, can the community add support for other databases)?

A: User code can be written in a database-independent way, depending only on an abstract profile which is implemented by different database drivers. New drivers can easily be implemented by 3rd parties as separate projects.

Q: Are there plans in the future to support other databases out-of-the-box?

A: At the moment Slick is limited to JDBC-based SQL databases. We are planning to support different kinds of NoSQL databases with non-JDBC drivers in the future as part of the Slick core release. Drivers for high-end commercial database systems will be available as a commercial add-on from Typesafe.

Q: Is a JDBC driver required to use Slick or does the Slick driver for a particular database handle it completely?

A: All database connections are made through JDBC using the standard JDBC drivers for the respective database systems. This makes it easy to integrate Slick into existing platforms, e.g. for using container-managed data sources or sessions in JEE environments.

Q: Does Slick make Java and Scala ORM solutions unnecessary?

A: Slick is not a drop-in replacement for an ORM but we believe it can provide superior results in many cases. Traditional ORM solutions focus on making the database disappear from your application, giving you the illusion of working with a network of mutable objects in memory. This comes with the usual problems of mutable state in general, plus additional challenges caused by the large impedance mismatch between the relational and object-oriented worlds. Slick makes heavy use of immutable data structures and concepts from functional programming which are much closer to SQL, thus staying clear of most impedance mismatch problems while providing much of the power of an ORM.

Conclusion

There seem to be many great ideas incorporated into Slick and I think it may be the feature that finally motivates me to make time to try out Scala. Thanks to Martin for responding to my questions and to Laura Masterson for arranging for the opportunity to have my questions about Slick answered.

Original posting available at http://marxsoftware.blogspot.com/ [16] (Inspired by Actual Events)