LINQ stands for Language INtegrated Query and in a nutshell, it makes query and set operations, like SQL statements, first class citizens in .NET languages. Watch an interview about LINQ here.
LINQ looks interesting, but the benefits of moving data access into the compiler level aren’t clear. SQLJ tried a rudimentary level of this concept for Java, and while it’s still used, JDBC is clearly the preferred method.
What is the benefit of doing this in the language rather than in SQL using a class library? It seems easier to swap out class libraries than language elements as standards change.
Although at first sight LINQ looks inflexible because sql access (specific to ms-sql server to be sure) is built into the language, that’s not the case. LINQ does not define any particular sql mapping at all, rather is simply defines a mapping from language constructs onto plain methods such that it’s still possible to swap libraries easily, and now with a guaranteed syntax 🙂 too…
LINQ itself is a set of language enhancements (starting with C# 2.0 and culminating with C# 3.0, and similarly with VB.NET) that enable a pattern of set-based, typed queries. In essence, it defines an object-oriented query language that can be translated into SQL, XQuery, or any other query language as implemented by a provider.
Microsoft will ship two providers, one called DLINQ (for SQL queries using ADO.NET) and the other called XLINQ (for queries over XML information). In the case of DLINQ, it is still the database that executes the query; the compiler simply writes the query and the ADO.NET glue code.
A major goal, put simply, is to allow your compiler to check your query strings, rather than waiting for runtime to discover errors.
Make no mistake, this is a +major+ contribution and will significantly shape the next generation of languages. Java will likely do something similar, because the utility is profound and undeniable. As was the case with annotations.
And of course don’t forget that you can query plain old .net data structures too… this kind of query capability makes using larger data structure much much more flexible, as you can express ideas without using quite the huge detailed implementation you needed before. The fact that you can then also redefine it manually so that you can use it over sql or xml or whatnot is rather an added bonus…
This is going to be huge: if you’re programming data views, you’ll want this. Just to compare, the success of ruby on rails is based soley on similar (but far less flexible) features. It’ll be interesting to see where other languages develop, because this sure is a killer feature.
Really. It’s not just some other microsoft feature in a forest of overwhelming marketingspeak…
AFAIK list comprehensions work on arrays, but Linq works on anything (e.g. sql, xml, arrays etc.). I would like to see how Python would do such thing. Also I don’t see how this is related to the static vs dynamic debate …
> AFAIK list comprehensions work on arrays, but LINQ works on anything (e.g. sql, xml, arrays etc.).
Wrong. List comprehension works on any iterables, which can be native list, plain file, xml, database, network, whatever. Things just need to implement iterator protocol.
But that probably means that Python has to load, say, whole database table to memory, and then filters it. Linq generates SQL and lets the database filter it.
I wonder. For server-based SQL access, will the closure that is the argument for the Where() method (see the video) get shipped off as a temporary stored procedure, or does the library have the opportunity to pick it apart and convert as much of it as it can to SQL?
I would’ve preferred they show more of the library-level stuff. The special syntax is nice but not all that exciting. You could probably do this with Nemerle macros.
What about modifying the database? Is there a syntax for that?
I think that the lambda expressions are converted to abstract syntax trees which are then translated to SQL ro something else. This is a Domain Specific Language (with multiple backend implementations for different data sources), not just a bunch of closures.
LINQ looks interesting, but the benefits of moving data access into the compiler level aren’t clear. SQLJ tried a rudimentary level of this concept for Java, and while it’s still used, JDBC is clearly the preferred method.
What is the benefit of doing this in the language rather than in SQL using a class library? It seems easier to swap out class libraries than language elements as standards change.
Although at first sight LINQ looks inflexible because sql access (specific to ms-sql server to be sure) is built into the language, that’s not the case. LINQ does not define any particular sql mapping at all, rather is simply defines a mapping from language constructs onto plain methods such that it’s still possible to swap libraries easily, and now with a guaranteed syntax 🙂 too…
LINQ itself is a set of language enhancements (starting with C# 2.0 and culminating with C# 3.0, and similarly with VB.NET) that enable a pattern of set-based, typed queries. In essence, it defines an object-oriented query language that can be translated into SQL, XQuery, or any other query language as implemented by a provider.
Microsoft will ship two providers, one called DLINQ (for SQL queries using ADO.NET) and the other called XLINQ (for queries over XML information). In the case of DLINQ, it is still the database that executes the query; the compiler simply writes the query and the ADO.NET glue code.
A major goal, put simply, is to allow your compiler to check your query strings, rather than waiting for runtime to discover errors.
Make no mistake, this is a +major+ contribution and will significantly shape the next generation of languages. Java will likely do something similar, because the utility is profound and undeniable. As was the case with annotations.
And of course don’t forget that you can query plain old .net data structures too… this kind of query capability makes using larger data structure much much more flexible, as you can express ideas without using quite the huge detailed implementation you needed before. The fact that you can then also redefine it manually so that you can use it over sql or xml or whatnot is rather an added bonus…
This is going to be huge: if you’re programming data views, you’ll want this. Just to compare, the success of ruby on rails is based soley on similar (but far less flexible) features. It’ll be interesting to see where other languages develop, because this sure is a killer feature.
Really. It’s not just some other microsoft feature in a forest of overwhelming marketingspeak…
How is this different from Python’s list comprehension (or generator expression) with itertools?
var result = from c in allCustomers
where c.ContactTitle.Length == 5
select c.ContactName;
This seems to be exactly equivalent to:
result = c.ContactName for c in allCustomers
if c.ContactTitle.Length == 5
Which is plain Python 2.4 syntax. Python reused “for” and “if” not to bloat number of keywords. Icon and Haskell had similar syntax for years too.
It’s still good to see static language camps playing catch-up.
AFAIK list comprehensions work on arrays, but Linq works on anything (e.g. sql, xml, arrays etc.). I would like to see how Python would do such thing. Also I don’t see how this is related to the static vs dynamic debate …
> AFAIK list comprehensions work on arrays, but LINQ works on anything (e.g. sql, xml, arrays etc.).
Wrong. List comprehension works on any iterables, which can be native list, plain file, xml, database, network, whatever. Things just need to implement iterator protocol.
But that probably means that Python has to load, say, whole database table to memory, and then filters it. Linq generates SQL and lets the database filter it.
I wonder. For server-based SQL access, will the closure that is the argument for the Where() method (see the video) get shipped off as a temporary stored procedure, or does the library have the opportunity to pick it apart and convert as much of it as it can to SQL?
I would’ve preferred they show more of the library-level stuff. The special syntax is nice but not all that exciting. You could probably do this with Nemerle macros.
What about modifying the database? Is there a syntax for that?
Who wants to start the PyLINQ project? 😉
I think that the lambda expressions are converted to abstract syntax trees which are then translated to SQL ro something else. This is a Domain Specific Language (with multiple backend implementations for different data sources), not just a bunch of closures.
Typed Queries already exist for.NET 2.0 without extending C# syntax, just using operators overloading.
http://www.lastcomponent.com/downloads/pdsinaction.wmv