DLinq Extensibility for Custom ADO providers?

What we have in the preview:
1. Interop with ADO.NET SqlConnection
2. .NET framework transaction model - that is *the* transaction model for DLinq and hence already includes SqlTransaction interop under the covers through TransactionScope.

What we are looking at (not in preview hence not in docs)
1. Extensibility for non-SQL Server databases. One possibility is an enhanced provider model along the lines of ADO.NET managed providers. (Of course, ADO.NET providers operate with relational abstractions whereas we would have to work out something at a higher level consistent with DLinq).

To be precise, the interop is with ADO.NET; not the pre-.NET framework ADO.

Please let me know if you had something else in mind.

Thanks.
Dinesh Kulkarni
Program Manager - The LINQ Project

DineshKulkarni at 2007-9-9 >

Since we are still exploring how to best support other databases, the following should be considered nothing more than my musings (may not be implemented, may be quite different, etc.):

- Unlike ADO.NET providers that do relatively minimal processing on the SQL, DLinq actually generates SQL based on mapping. So the nature of the provider is likely to be quite different. That said, I would expect additional work to be layered over an ADO.NET provider. The base functionality of an ADO.NET provider is necessary but not sufficient.

- ADO.NET providers support a set of APIs - some of them taking strings. DLinq is about language integrated queries (expression trees when the compiler is done) rather than an API. So it presents some additional challenges. DLinq does have an API for persistence but it is small with rich semantics (consider all possible object graphs with tricky foreign key dependencies). So even if we take the "provider" route, it may look quite different.

In a nutshell, you may not have to "change" anything from an ADO.NET provider but there _may_ be plenty of additional work to bridge the O-R gap!

DineshKulkarni at 2007-9-9 >