2009 06 11 a lot of progress in work

Published on June 11th, 2009 at 13:54

A Lot of Progress in Work

In case you've missed it: re-linq is currently undergoing major changes. (In case you've also missed what re-linq is: Stefan Wenig has recently explained that.)

Some of it can be deducted when reading what Stefan posted about LINQ-to-NHibernate on Ayende Rahien's blog:

I'll try to shed some light on the current status of the new LINQ provider.

Steve Strong clearly has the lead here, and I hope I don't misrepresent his part here (especially since he's OOF for a few days, so check back if you expect a comment from him).

What has already happend?

1. Steve has created a new HQL parser that will replace the current one in NH. [...]

2. Here at rubicon, we made an OSS library for creating LINQ providers, called re-linq [...].

3. We're in contact with Steve about creating LINQ to NH using re-linq.

[...]

In fact, we got some good feedback from both Ayende and Steve about using re-linq as a foundation of NHibernate's LINQ provider. That's why we (as a company) decided to put some time and effort into refactoring re-linq in several different steps, moving parts to better places and adding features to make re-linq the ideal foundation for NHibernate's LINQ provider.

In particular, we are planning to implement the following tasks:

1. We want to make re-linq capable of parsing virtually any query. Even such queries that contain expression types defined by the user, or by the specific LINQ provider built on re-linq.
   For this, we need to replace the structural parsing classes that construct the QueryModel and Clause instances to make for a more flexible and extensible parsing experience.
   (In fact, this has already been implemented by now.)
2. We want to make re-linq capable of parsing queries that do not follow the patterns exposed by the typical .NET compilers. These patterns allowed us to make assumptions when resolving the predicate and selector expressions used by Select, Where, SelectMany, and similar clauses. The problem is: these assumptions don't hold when a query is hand-written, so we need to implement a resolution algorithm that does not depend on them.
   The result of this will be that the clauses produced by re-linq will contain predicate and projection expressions that directly point back to the clauses where the used data stems from, which should make it easy to generate queries from those clauses.
3. After those two changes, we will be able to clean up the clause classes a lot.
4. One of the big challenges of generating queries from LINQ expressions is to transform what was written by the user into something that can be expressed in the target query language. Let clauses, for example, generally cannot be expressed in SQL in a good way. However, at least as long as they are side effect-free, you can simply insert their right sides everywhere their left side is used.
   Similarly, as Frans Bouma recently explained, Where clauses sometimes have to be moved to the right side of Join clauses to avoid derived table expressions. 
   We want to make such transformations really easy to perform, and we will refactor the clause classes and QueryModel to facilitate this.
5. We need to supply a parser for Queryable.Join, as parsing this is currently not implemented. This is a little embarrassing, but in re-store queries, we usually use implicit joins (order.Customer) rather than explicit joins (from o in Order join c in Customer on ...), so we didn't really need this until now.
   Fortunately, this is really easy to implement after task number 1.
6. We also need to provide a parser for Queryable.GroupBy.

And that's the plan, mostly.

About the time frame; at the time of this writing, issue number 1 has been finished. We are now working on issue number 2, most of which has already been implemented, but which still needs to be integrated with our SQL-generating backend. The other big changes (tasks 3-4) should be made by the beginning of July, I hope.

That's a lot of work in progress with re-linq. And the goal? To make it the perfect LINQ provider foundation.

Update (2009-06-12): Steve Strong has also posted about this topic.