A. LINQ support:

There will be no more OQL in v4.0. We're going to provide several new ways of querying the database:

• 1. Using RSE (RecordSet Engine). RSE is new, full-featured built-in query evaluation engine. It evaluates queries defined in form of query plan - normally any SQL database first produces such plan for the query, and then - evaluates it. So it's a kind of low-level API allowing to do query everything exactly as you like.

• 1.1. Using "true" RSE - this implies you define the query as tree of RSE providers (single operation in query plan = single RSE provider), which leafs are IndexProviders. Evaluation of such query (i.e. joins, filtering, index seeks, etc.) is performed by RSE - locally, remotely, or on both \ multiple sides (we hope some day our indexes will be distributed).

• 1.2. Using "SqlDom to RSE" - it is an RSE provider that will be available for any SQL database representing a result of SQL DOM (Xtensive.Sql) query as our RecordSet object bound to persistent model (i.e. with mapping).

• 2. Using LINQ. For now nothing is done here, but we're planning to write both LINQ-to-1.1 and LINQ-to-1.2 case translators further. So finally you'll be able to do everything just with LINQ.

Why case 1.2 is necessary? In case 1.1 any SQL database is queried only by index-based queries (fetch index range \ record \ aggregate), and all further evaluations will be performed on DO level. This (at least) implies higher RDBMS-to-DO data throughput, which is certainly not desirable.

On the other hand, 1.2 isn't necessary for our own storages at all, since they evaluate RSE. If the underlying storage works locally (i.e. in the same AppDomain where DO works - that's true for in-memory and file system storage providers, if they aren't "shared"), case 1.1 brings such benefits as better caching: everything you "touch" in indexes is immediately registered in DO caches, and needs no further queries to be fetched.

Above features will be implemented in sequence listed above. Right now we're intensively "fighting" with case 1.1.

D. Lazy computations:

As you understood, DO itself finally deals just with RSE-based queries. But RSE in initially designed to use lazy computations everywhere: when you create or deserialize an RSE provider, normally nothing happens (except validation in some cases). But when you start to enumerate it for the first time, it gets compiled (this may lead to appearance of sequence of "real" providers below it) and finally - evaluated. There are two kinds of providers:

• Ones do all the job on the first evaluation attempt, and further just provide the results from some in-memory structure. An example of such provider is sorting provider.

• Anothers are true lazy providers - they don't maintain the full result in memory, but instead evaluate the next part of it when it's enumerated. Examples are filtering, join, index and SQL DOM query providers.

B,C. Type inference and anonymous methods, lambda expressions:

These features (except lambda expressions) don't require some "special" support in LINQ - they're purely C# 3.0 syntax sugar, i.e. you can't find "var" or anonymous method in MSIL. Lambdas are what allow LINQ to work, so they'll be definitely supported ;)

Concerning usage of them in our own code: we use all features of C# 3.0 now, including LINQ \ PLINQ, when this is appropriate (e.g. to filter an IEnumerable). This also mean we'll provide support for them everywhere, where this will be appropriate as well.