The missing LINQ

In my last column, one of the issues I raised was over the need for LINQ (Language Integrated Query) as yet another data query language. I was pleased to receive a large number of emails agreeing with my view, plus a few pointing out the advantages of LINQ over SQL. Interestingly, most of the emails against LINQ were from people like myself, who’ve spent many years in the IT sector and whom it might be easy to dismiss as “grumpy old gITs”, which is what Mark Saragossi of Octa suggested we might be called. But that would be to ignore all those years of real-world experience in jobs where the need to produce working, reliable code on time is far more important than to code using the latest – often untried – technologies.

Some correspondents, such as Gouranga Gupta of Omnibus, suggested that rather than introducing a completely new syntax LINQ’s array concept could perhaps be extended to include SQL-like functionality. That way, we could collect data into a dataset array and then query it using a language that’s well understood. Some of the emails suggested that LINQ has the advantage over SQL in being a language feature of VB9 and C#3 and, as such, is fully supported in Visual Studio 2008. So, why can’t SQL also be raised to this lofty level?

Another point is that LINQ queries can be made as complicated as you like and will be optimised down into more efficient SQL by the system. However, the query optimiser in SQL does this already to your existing queries and, anyway, most of us have long since learnt what works well as far as queries go, so this is hardly a reason for moving to LINQ. Others, such as Alex Macklen, outlined certain advantages of LINQ’s type checking, which may help when transferring data from Oracle with its UTF-8 text to a system that uses Unicode strings, and offers the ability to reduce round trips to the server by using heterogeneous operations – that is, ones that dynamically read data into a dataset held in memory that can be queried by LINQ again and again with no further server access. Similar behaviour can be achieved in SQL Server by caching, but there’s still a call from your server running the code to the server that holds the database.

Obviously, it’s important that there are people out there thinking about the way database technologies should develop, and about new answers to both old and new problems. For me, however, the biggest issue is that we already have a query language so well established that it isn’t going away any time soon, so why not extend that language to fit today’s needs rather than creating a completely new syntax? One gets a suspicious feeling that such decisions are made by in-groups more concerned with what will be judged “cool” than by considerations of real-world utility. It all reminds me of that late beta of Windows, which we’re told was very near to release code, only to find that it couldn’t print to network printers. It makes you wonder sometimes what these people do all day.

Let’s get LINQing

Having devoted these column inches to saying that there’s no need for LINQ, this next section will now explain to you a really useful application of the technology. I often find myself wanting to query the filesystem to get information about the files it contains: for example, an upload folder held on a web server. Doing this via SQL involves writing lots of code and invariably doesn’t work very reliably, so it was with interest that I read how LINQ should be able to do this better. I stand by my view that SQL ought to be enhanced to make this possible, but until it is you may be interested to see how to query the filesystem via LINQ. I recommend you first download the free Express version of Visual Studio 2008, which is now on public release; its improved IntelliSense and fuller support for Ajax extensions will make coding much easier, and it will at the same time install .NET Framework 3.5, which you’ll be needing. Please do this download into a spare virtual machine just in case it messes up your old code.