EFExtensions , released on CodeGallery earlier this week by EF team member, Colin Meek, has a lot of brainy goo in it. So far I’ve looked at the pieces that Colin has explained in his first post (first post ever) about the Extensions. While most of the extensions in the first part of his post are replicating what Object Services does, the last chunk displays the real benefit of having them at hand.

EF Function Imports can handle READ stored procedures that return existing entity sets. At first I was looking at the extensions to see if they can return random objects, but I haven’t seen that yet however there’s a lot to look at still. (I’m picturing a generic method that reads the columns and creates an anonymous type on the fly rather than having to go through all of the mucking with the model to make this work. Of course, this is for read-only results.)

What Colin’s post shows, however is sprocs that return shaped results. A standard function import can’t do this…it needs to map to a single entity type.

So by combining a few of his extensions, he is able to extract the different types from the shaped results and mimic the object materialization that happens under the covers in expected scenarios. Additionally, he is able to add these entities manually into the change tracker.

It’s pretty sweet and what’s funny to me is that I was trying to do something very similar to this on the same day that Colin released the extensions. I had seen them pop into Code Gallery, made a mental note and a quick blog post without digging into them yet, then a few hours later asked on the forums, “Any way to grab sets of (unrelated) entities in one database call? “. Small world, eh? Now that I have a better understanding of some of the extensions, I will have to go back and see if this does the trick.

Is Entity Framework right for your Applications? You’ll probably want to answer this question before you start digging in deeply to learn this new data access platform that will be released very soon. Does it fit into my architecture? Will my DBA allow it? How will it play with my existing solutions? This BOF is intended as an interactive discussion where there will be plenty of experts in the room to get you started with some important decision making.

It won’t happen unless it gets voted for so go vote!

Roger Jennings wrote a dizzying (in a good way) post about stored procedures that I have not even had the chance to absorb yet but it’s about creating database procedures after the fact that can be easily used with the entities and associations defined in your model.

Coincidentally, Noam Ben-Ami wrote a lengthy post on teh ADO.NET Team blog about using the designer to leverage DML stored procedures that already map directly to entities defined in teh CSDL, while the stored procedures might do perform additional functions, such as time-stamp checking. Stored Procedure Mapping

In the EF forums, Danny Simmons lets an EF RTM cat out of the bag.

And, this looks like it has the possibility to be bigger than just for EF. The EF team worked with the WCF team to make ENTIRE GRAPHS serializable, and in an interoperable way. If you look at Ruurd Boeke’s blog post,Circular references with WCF: solved a different way, about how he  achieved this, you can see examples of how WCF serialized entities before (non-interoperable) and after his own tweaks. Ruurd has been thinking about this problem for a long time, not just for EF, but for WCF in general, because it’s the way that WCF serializes that causes the problem.

So the question is, did they just implement this specifically for EF, or will this have a broader impact? We’ll see when the next CTP (as per Danny’s comment, he says CTP not Beta4) of EF comes out.

It’s great to see Colin Meek finally blogging. Colin has been a wealth of information on the MSDN Forums for Entity Fraemwrok related questions. It is also COlin who posted teh Entity Framework Extensions on CodeGallery a few days ago.

Colin talks about the extension in his first post and how they can be used to handle a variety of Stored Procedure scenarios in Entity Framework.

For what looks like a pretty complete list of the blogs of the Entity Framework team and others on the Data Programmability team at Microsoft, see the Resources page of the DataDeveloper.NET website.

Thanks to Alex for the heads’ up….

Because of a bug in the way the schema files are created, the behavior for embedding the model into your assembly and the impact on using that assembly in other projects is a little funky. This will change with the next iteration of the EF that we will see as it has been fixed.

In the meantime, there are two things to keep in mind.

1) When you compile, even if you want the files embedded, choose the Copy to Output Directory option for Metadata Artifact Processing, then build, then change the option to Embed in Output Assembly.

2) If you make a change to the model and rebuild, after it is already being referenced by another project, you may or may not get the changes reflected in the assembly and therefore the client project will still fail. In most cases, doing the 2-step build will do the trick. In other cases, it is necessary to go into the bin directory of the model’s project and delete all of the schema files (csdl, msl & ssdl) or just delete every thing in there, then do the two step rebuild again.

As I’ve been working on samples over and over and over, and adjusting my model, I’ve gotten into the habit of doing this.

One easy red-flag that you need to do this is if you get an error message complaining about C-side vs. O-side. That means that something in the CSDL is different than the classes (O=Objects) that were codegen’d. So you while the assembly does have the updated classes, it doesn’t have the updated model.