ScalaQL: Language-Integrated Database Queries for Scala Daniel Spiewakand Tian Zhao … core framework is not restricted to merely database access; it has also been applied to other query … One of the most ubiquitous elements of modern computing is the relational database. Very few modern applications are created without some sort of databasebackend. Unfortunately, relational database concepts are fundamentally verydierent from those used in general- purpose programming languages. This creates an impedance mismatch between the the …

One of the most persistent problems in modern application development is that of logical, maintainable access to a relational database. One of the primary aspects of this problem is impedance mismatch [7]between the relational model and the paradigm employed by most general-purpose programming languages. Concepts are expressed verydierently in a relational database than in a standard memory model. As a result, any attempt to adapt one to the other usually results in an interface which works well for most of the time, but occasionally produces strange andunintuitive results. One solution to this problem of conceptual orthogonality is to\give up” attempting to adapt one world to the other. Instead of forcing objects into the database or tables into the memory model, it is possible to simply allow the conceptual paradigms to remain separate. This school of thought says that the application layer should retrieve data as necessary from the relational store by using concepts native to a relational database: declarative query languages such as SQL. This allows complete exibility on the database side in terms of how the data can be expressed in the abstract schema. It also gives the application layer a lot of freedom in how it deals with the extracted data. As there is no relational store to constrain language features, the application is able to deal with data on its own terms. All of theconict between the dissonant concepts is relegated to a discrete segment of the application. This is by far the simplest approach to application-level database access, but it is also the most error-prone. Generally speaking, this technique is im- plementedby embedding relational queries within application codein the form of raw character strings. These queries areunparsedand completely unchecked until runtime, at which point they are passed to the database and their re- sultsconverted using more repetitive and unchecked routines. It is incredibly easy even for experienced developers to make mistakes in the creation of these queries. Even excluding simple typos, it is always possible to confuseidentier names, functionarities or even data types. Worse yet, the process of constructing a query in string form can also lead to serious security vulnerabilities |most commonlySQL injection. None of these problems can be found ahead of time without special analysis. The HolyGrailof embedded queries is to ndsomewaytomake the host language compiler aware of the query and capable of statically eliminating these runtimeissues. As it turns out, this is possible within many of the.NET language family througha framework known as LINQ[8]. Queries are expressed using language-level constructs which can beveried at compile-time. Furthermore, queriesspecied usingLINQalso gain a high degree ofcomposability, meaning that elements common to several queries can often be factored into a single location, improving maintainability and reducing the risk of mistakes. It is very easy touse LINQto create a trivial database query requesting the names of all people over the age of 18: var Names=from pin Person wherep.Age>18 selectp.Name; This will evaluate (atruntime) an SQL query of the following form: SELECT name FROM people WHERE age>18 Unfortunately, this sort of embedding requires certain language features which are absent from most non-homoiconic[10]languages. Specically, theLINQ framework needs the ability to directly analyze the structure of the query at runtime. In the query above, we are filltering the query results according to the expression p.Age>18. C#evaluation uses call-by-value semantics, meaning that this expression should evaluate toabool. However, we don’t actually want this expression to evaluate. LINQ needs to somehow inspect this expression to determine the equivalent SQL in the query generation step. This is where the added language features come into play. While it is possible for Microsoftto simply extend their language with this particular feature, lowly application developers are not so fortunate. For example, there is noway for anyone (outside of Sun Microsystems) to implement any form of LINQ within Java because of the language modications which would be required. We faced a similar problem attempting to implement LINQ in Scala.

Download ScalaQL: Language-Integrated Database Queries forScala.Pdf