Today Entity Framework team released an update to Sample Provider for Entity Framework 4.0. The provider is intended to be an example for ADO.NET provider writers but can also be used and hacked upon by everyone interested in the inner workings of an EF provider.

The sample can be downloaded from MSDN Code Gallery. It is licensed under Microsoft Public License (Ms-PL). EFQuerySamples includes additional examples of configuring and using the sample provider.

I’ve just posted a tiny update to EFProviderWrappers sample. It fixes the issue which was reported to me by several users, where NotSupportedException was being thrown during SaveChanges() from caching provider code.

You can download updated bits from MSDN Code Gallery. If you find any other issues, please report them as comments here.

Kati from EntityFramework team has published a detailed post about improvments in generated SQL in Entity Framework v4.0. The improvements are really impressive and make generated SQL perform better and and look much closer to hand-written query code. The best thing is: almost all of the improvements are provider-agnostic, so you will see automatic improvement on queries running on 3rd-party providers. In some cases (LIKE optimization) you will need to use EF4-specific version of the provider.

Entity Framework/Code First feature released as part of Feature CTP 3 can work with any EF-enabled data provider.

In addition to regular providers which target databases, it is possible to use wrapping providers which can add interesting functionality, such as caching and tracing. In this post I’m going to explain how to use EFTracingProvider to produce diagnostic trace of all SQL commands executed by EF in Code First.

Setting up EFTracingConnection

In order to use the tracing provider, we need to create a wrapping DbConnection which adds logging every time the command has finished execution. The following helper will set up such connection. As you can see it can log commands to the console, log file or both. Plugging in additional logging mechanisms (such as System.Diagnostics, NLog or log4net) should be trivial.

Object Context Factory

In order to efficiently manage tracing for the application we need to create a central factory class which will create ObjectContext instances for us. This is the place where we will create tracing provider connection and use it to instantiate ObjectContext.

Assuming our Object Context class is called MyContainer, the factory class will be called MyContainerFactory and will have a method called CreateContext, so the usage becomes:

Sample Project

In the spirit of Code Only the project does not have any non-source artifacts (not even App.config file) and configures everything (model, mapping, tracing) through code:

Here is the output you get when running the application – as you can see all statements are logged to the console – log file is also created with similar output.

Limitations

There is a known issue with this technique where creating databases is not supported on SqlClient provider. Other providers may or may not support this functionality depending on implementation. In general, because of that it is recommended to use unwrapped connections when using DDL APIs (CreateDatabase, DeleteDatabase, DatabaseExists()) as demonstrated in the sample.

Now that Visual Studio 2010 and .NET Framework 4.0 have been released, users of Entity Framework can use POCO objects with Entity Framework without the need for wrapper layers such as EFPocoAdapter. Since I know a number of people are using EFPocoAdapter in their production applications and it is not supported, I recommend they migrate to using native POCO support in EF v4.0 which is the supported way of using POCOs from now on.

This post will highlight the differences between EF and EFPOCOAdapter, which you must keep in mind when migrating your code base.

One of the users has reported a problem with using EFProviderWrappers and precompiled views together.

When you pre-compile views, Entity Framework calculates a hash of metadata (which includes csdl,ssdl and msl information), stores it with the generated views and compares it later when metadata is loaded. When loaded metadata doesn’t match the hash stored in pre-compiled views, an exception is thrown. […]