Microsoft LINQ Books

Will Oracle and DB2 support be a standard day-1 feature?

Thanks!

In the RTM of Visual Studio 2008 and .NET 3.5, LINQ to SQL will support only Microsoft SQL Server and Microsoft SQL Server CE. There are no plans to support other databases. LINQ to Entities (the LINQ interface to ADO.NET Entity Framework) will support any database supported by ADO.NET Entity Framework. In this case there is a documentation available to build a ADO.NET Entities provider, thus each SQL vendor can implement its own ADO.NET Entities driver, allowing LINQ to Entities to operate with several differents RDBMS.

This came at a cost: LINQ to SQL should be faster than LINQ to Entities, but the product is still in beta and it's too early to do real benchmarks.
Finally, ADO.NET Entity Framework will be shipped some months later than Visual Studio 2008 and .NET Framework 3.5.

 Marco

Hi Marco,

Could you point me to documentation on writing an ADO.NET Entities provider?

Or even better, could you comment on my problem and advise me what I need to do:

I have an internal API which basically allows me to execute SQL statements and procedures and I would like to use this API with Linq syntax. The SQL syntax supported by this internal API is similar to SQL Server's SQL syntax.

So I could implement,

• "Linq to internal API"
• An ADO.NET Entities provider on top of the internal API

Both options would probably require a lot of work. Initially, I would be happy if I could use Linq to SQL or Linq to Entities with a few "customizations" to take care of differences in SQL syntax, in the actual API call needed to execute SQL commands, types needed etc.

Your comments to this would be highly appreciated!

Thanks

Look at this post to write an ADO.NET Entity Framework Provider: http://blogs.msdn.com/sceppa/archive/2007/12/18/sample-ado-net-entity-framework-provider-beta-3.aspx - this is your case 2)

We wrote a chapter in the upcoming "Programming LINQ" book which describes how to write an IQueryable provider, which is your case 1)

I don't know very much how complex the writing of an ADO.NET Entity Framework provider is. Please let me know what is your idea after looking at sample I linked before.

Marco

Well, after thinking about it for some time, I guess what I need is to be able to write queries that work on both LINQ to SQL and my own LINQ to Internal API. I imagine that a factory class would pass out an implementation of the context (DataContext in LINQ to SQL) so I can decide at run-time what implementation to run.

I have not seen your chapter on implementing an IQueryable provider - is it along the lines of Matt Warren's blog (http://blogs.msdn.com/mattwar/archive/2008/01/16/linq-building-an-iqueryable-provider-part-ix.aspx)? I hope you in this chapter will describe how the implemented provider relates to LINQ to SQL - and how to choose one or the other at run-time. I am unsure about how too hook in the provider.

Maybe I simply need to read and think a bit more. However, if you have done the thinking already I would very much like to hear about it:-).

Thanks,
Brian

It seems difficult to me.

You should wirte a "wrapper" provider that duplicates all metadata of LINQ to SQL and that creates a LINQ to SQL query tree starting from a "your-provider" query tree. I didn't spend time to think to other details, but this shoul probably need this approach...

Marco

I think you are right. I had hoped for more commonality among LINQ implementation than just IQueryable. What is the point of an OR mapper if it can only map to a single DBMS family? Yes, I know, LINQ to SQL is a very easy and fast way for common scenarios on SQL Server. I just had hoped for something in its architecture that would help me access other DBMS as well.

Will you take up this topic in your new book, the (lack of) commonality among LINQ implemenations and what to do about it?

Should I look to LINQ to Entities instead?

Thanks,
Brian

Yes, LINQ to Entities is built on ADO.NET Entity Framework, which is already compatible with several DMBS. However, if you compare LINQ to SQL with LINQ to Entities, the first is faster when you're working on SQL Server. Each feature comes at a price...

Marco

Linq to entities was apparently a bit disappointing.
There is an open source project, DbLinq, which currently supports Oracle and a few other databases (DB/2 is planned, but not a priority... Not yet).
The project page is at http://code.google.com/p/dblinq2007/