Object-relational mapping solutions have made working with databases from an object-oriented language easier. O/R mapping solutions, however, still require developers to use different programming interfaces to handle language-based collections and collections that reside in databases. Language-integrated querying, a technique pioneered in a widely-used, mainstream programming language by Microsoft, aims to bridge that divide.
In a recent paper, Extending Scala with database query capability[PDF], Miguel Garcia, Anastasia Izmaylova, and Sibylle Schupp explain the benefits of bringing language-integrated querying to Scala and, by extension, to the JVM:
In a nutshell, the main advantages of language-integrated query are its compile-time type safety and the resulting conciseness of expression due to type inference and compact notation for common operations, such as grouping and sorting...
Unlike the situation for “normal” programming language constructs, a compiler is not aware of the semantics of embedded database queries, and thus offers no help regarding their well-formedness checking (e.g., to detect queries broken due to a reorganization of the database schema) or their processing (e.g., in optimizing the query before shipping it to the DBMS for evaluation). Approaches to overcome these shortcomings fall under the general umbrella of language-integrated query, of which embedded SQL is an early example and Microsoft LINQ ... today’s best-known representative...
We present a solution where the developer may express queries encompassing program and database data. The notation used for queries is based on comprehensions, a declarative style that does not impose any specific execution strategy. In our approach, the type safety of language-integrated queries is analyzed at compile-time, followed by a translation that optimizes for database evaluation. We show the translation total and semantics preserving...
We provide an implementation in terms of Scala compiler plugins, accepting two notations for queries: LINQ and the native Scala syntax for comprehensions...
What do you think the approach to language-integrated query based on Scala compiler plugins?
Quite interesting; I should note that Apple is moving C in a more flexible direction as well (with LLVM and Clang, both of them designed so that programmers can extend them by writing their own passes).
The code is unfortunately not available yet -- the university's STS group has individual project pages for their other projects, but the ScalaQL page links back to the group page.
In my C++ apps, what I did is to declare the schema as a set of objects, then use these objects to form queries, instead of raw SQL. When the schema objects were created, they checked themselves against the database, and thus if there was a mismatch, it was immediately known when the program was launched.
In my C++ apps, what I did is to declare the schema as a set of objects, then use these objects to form queries, instead of raw SQL. When the schema objects were created, they checked themselves against the database, and thus if there was a mismatch, it was immediately known when the program was launched.
Is there a reason why SQL can't be statically checked? I think it could be nice to validate my queries at compile time. I just don't understand why we need new languages to do this.
> Is there a reason why SQL can't be statically checked? I > think it could be nice to validate my queries at compile > time. I just don't understand why we need new languages > to do this.
That's a very good point. The more I learn about SQL, the more I ask that question.
> The SQLJ implementations statically checked SQL back in > the 90's. > > http://en.wikipedia.org/wiki/SQLJ > > Since 'correct' is a subset of 'syntactically correct' and > 'correct type', unit tests of queries dramatically reduce > the value of this checking. > > Linq done right makes unit testing easier.
Sorry. I don't follow. What does unit testing have to do with static checks?
> Sorry. I don't follow. What does unit testing have to do > with static checks?
Unit tests and static checks have the same purpose. They find faults in code.
It no accident that the current unit test tools evolved in an environment with no static type checking. It is because unit tests have more value there.
The value of unit tests and static checking are highly related in many ways. If you have static checks you need less unit tests, because more is guaranteed by static compiler checks. On the other hand if you have high unit test coverage, static tests are less valuable because issues they find are already apparent from failing unit tests.
Consider a development environment where you write code test first, and your unit tests execute in the background automatically. If you make an error in the query syntax you will rapidly get an failure telling you about the fault in your code. A static check will also tell you about the same fault, but who cares, you already know.
Tools like Linq provide an abstract query model. It is possible implement this over the top of simple language collections making unit tests of queries simpler and more efficient.
If you are really serious about static checking of queries you need more ways of expressing constraints, analogous to pre and post conditions. If we are only getting syntax and type checking then perhaps a better trade off would be to loose the complexity and facilitate better dynamic fault finding techniques.
> > Sorry. I don't follow. What does unit testing have to > do > > with static checks? > > Unit tests and static checks have the same purpose. They > find faults in code.
That's commonly repeated but it's not really the case. Static checks enforce constraints. These constraints allow certain things to be known about the code. In the case of SQL, one of the obvious benefits would be code completion. I've worked with tools that do code completion on SQL so I know that at least is possible.
Other benefits would be the ability to reliably find dependencies, determine the impact of changes before making them, and ease integration with statically typed languages.
There is some overlap between the benefits of unit testing and static checks but neither can replace the other. Don't get me wrong, I think that dynamic languages are extremely useful in the right context. For many of the uses of SQL, however, I don't see any benefit. This is mainly because the DBMs is usually going to statically compile the SQL anyway. The only difference would be taking that capability and integrating it with the development tools that are using the queries, inserts, and updates.
> Tools like Linq provide an abstract query model.
SQL provides an abstract query model. This is not a difference.
Are we all reinventing something substantially worse that the Mnesia/Erlang system? It not only seems better than most of what is proposed, it is also simpler, more solid and mature.
I think the dynamic/static question is the wrong thing to look at. The issue is two models that are not talking to each other, but interact highly, and share one domain. That is why language integration is an important area.
> That's commonly repeated but it's not really the case. > Static checks enforce constraints. These constraints > s allow certain things to be known about the code. In the > case of SQL, one of the obvious benefits would be code > completion. I've worked with tools that do code > completion on SQL so I know that at least is possible.
RapidSQL does some completion on SQL, I use it most days.
IDE's could infer that parameters to functions call "createQuery" are queries and do completion on those. And do the @NamedQuery annotation too.
> Other benefits would be the ability to reliably find > dependencies, determine the impact of changes before > making them,
Sounds great. I think this requires some constraints that may not always be realistic.
> and ease integration with statically typed > languages.
I think this one is the killer feature for being able to inject stuff into the compiler. Of course the problem goes away in dynamic languages...
> > There is some overlap between the benefits of unit testing > and static checks but neither can replace the other.
I like both. But I think you can get what I want in a dynamic setting. There are plenty of projects that don't do either. Perhaps Mercurial is an example:
> Don't get me wrong, I think that dynamic languages are > e extremely useful in the right context. For many of the > uses of SQL, however, I don't see any benefit. This is > mainly because the DBMs is usually going to statically > compile the SQL anyway. The only difference would be > taking that capability and integrating it with the > development tools that are using the queries, inserts, and > updates.
I tend toward the opposite view. When code is database intensive and the type system is largely ignorant of the model, so you might as well go dynamic. I.E. the type system is all cost and no benefit in the standard database application. Even more so if the type system does not understand the data the UI needs and supplies as in a Web application that uses something like freemarker or JSP.
> > > Tools like Linq provide an abstract query model. > > SQL provides an abstract query model. This is not a > difference.
Good point, an implementation of SQL on top of native containers would be able to handle unit testing of queries quite nicely.
> I tend toward the opposite view. When code is database > intensive and the type system is largely ignorant of the > model, so you might as well go dynamic. I.E. the type > system is all cost and no benefit in the standard database > application. Even more so if the type system does not > understand the data the UI needs and supplies as in a Web > application that uses something like freemarker or JSP.
I'm really only looking for some good IDE support. Ultimately, the DBMS is going to validate my SQL. Sometimes I go dynamic with the SQL and generate it on the fly. I also sometimes dynamically handle static query results or inserts. This kind of feature wouldn't help for that.
But for a lot of the stuff I work on, if the column names don't match up with what I am call them in my code, it's just going to break. Obviously testing will catch this but I'm lazy. I want the IDE to yell at me when I fat fingering it. I also have issues where I want to change the name of a column move things around. I'd like refactoring support or at least little red flags telling me what I need to fix.
It's not a necessity. I get by as is. It would be nice, though, especially for people who have to maintain what I have done. What I would really like to see is something where I create a .sql file and it's compiled into bytecodes with read methods for all the columns in the result and write methods for all the parameters.
> > > Tools like Linq provide an abstract query model. > > > > SQL provides an abstract query model. This is not a > > difference. > > Good point, an implementation of SQL on top of native > containers would be able to handle unit testing of queries > quite nicely.
In my original post to this thread, I really didn't mean this as a rhetorical question. I believe it's quite possible that there is a reason. I mean the people behind things like LINQ must have a reason, right? I just don't know what it is. One thing about SQL that is problematic is that it's not as standardized as it should be. That's a problem but it doesn't seem like enough of a reason to create a new language.
> In my original post to this thread, I really didn't mean > this as a rhetorical question. I believe it's quite > possible that there is a reason. I mean the people behind > things like LINQ must have a reason, right? I just don't > know what it is. the reason that the selected columns are last and not first is that you can do code completion. This is the only deliberate difference. Apart, from that LINQ is not a language, but a set of keywords that are processed by the C#/VB preprocessor. This is the other reason that LINQ is not exactly SQL.
> > In my original post to this thread, I really didn't > > mean this as a rhetorical question. I believe it's > > quite possible that there is a reason. I mean the > > people behind things like LINQ must have a reason, > > right? I just don't know what it is. > > the reason that the selected columns are last and not > first is that you can do code completion. This is the only > deliberate difference.
That makes sense and all. But I'm not convinced that it's hugely important.
> Apart, from that LINQ is not a language, but a set of > keywords that are processed by the C#/VB preprocessor. > This is the other reason that LINQ is not exactly SQL.
What's your definition of a language? I don't consider the mechanics of how it's interpreted to have any bearing on whether something is a language or not.
Flat View: This topic has 20 replies
on 2 pages
[
12
|
»
]
Previous Topic
