ADO.NET team blog : ADO.NET

There is still time to make yourself heard

dpblogs — Tue, 10 Nov 2009 00:29:00 GMT

The ADO.NET Providers team still needs your input. This is the last week to answer our ADO.NET Managed Providers Planning survey. Help us to make the decisions that will benefit our database community.

The survey can be found at http://blogs.msdn.com/adonet/archive/2009/11/01/the-ado-net-providers-team-wants-to-hear-your-opinion.aspx.

Thanks
Luiz Fernando Santos
Program Manager, SQLClient

VS2010 and .NET Framework 4 Beta 2 Announced!

dpblogs — Tue, 20 Oct 2009 00:56:00 GMT

Visual Studio 2010 and the .NET Framework 4 Beta 2 are now available for download by MSDN subscribers and will available to the rest of the world on Wednesday. Beta 2 as well the VS2010 Launch date of March 22, 2010 were announced this morning on Soma’s blog.

Included in Beta 2 are some great new features and updates for the Entity Framework 4 and ADO.NET Data Services 4.

Entity Framework 4 Beta 2

In addition to all of the new EF 4 features that were included in Beta 1, Beta 2 also includes:

Foreign Keys: EF 4 now includes a new type of associations (Foreign Key Associations) that allow you to have Foreign Key properties on your entities. Foreign Key Associations simplify some key scenarios such as Data binding and can be included or excluded when using the model creation and update wizards. Independent Associations supported in .NET 3.5 remain as is, but Foreign Key Associations become the default type of association going forward. Referential integrity constraints can now be created from the designer.
Improvements to POCO Support: Fix-up of changes to navigation properties and FKs is now performed automatically on DetectChanges and SaveChanges. It is also now possible to declare collections as ISet<T> in POCO objects. When either ICollection<T> or ISet<T> is used, the default collection type materialized is HashSet<T>, which among other advantages does not allow duplicate entries.
Lazy Loading on by Default in new Models: When you create a new model in VS 2010, you get generated ObjectContext types that have lazy loading turned on by default (context.ContextOptions.LazyLoadingEnabled = true is placed in the constructor). This simplifies the default experience of working with objects. Of course, it is still possible to turn it off and do explicit and eager loading.
EntityDataSource support for Query Extenders and POCO: EntityDataSource now includes support for ASP.NET Query Extenders and POCO entities. Query Extenders are a new addition to ASP.NET that allow you to have more control over the data retrieval query of a Data Source, leveraging the LINQ capabilities of Entity Framework.
Support for Binary Keys: The EF now allows you to have binary property types (and varbinary storage columns) mapped as Entity Key / Foreign Key.
ObjectMaterialized event: It is now possible to write logic that is executed immediately after an object has been materialized. This event is raised after the scalar, complex and reference properties are populated (collections are filled afterwards).
Object Services API improvements to enable N-Tier and Self Tracking Entities: ObjectStateEntry.GetUpdatableOriginalValues method provides a access to an updatable data record that you can use to establish the original state of an entity at the property level.
Improvements to the generated SQL: Numerous simplifications and improvements of the SQL generated when querying using the Entity Framework have been done including: removal of joins, better translation of certain functions, elimination of constants used for internal purposes, which results in removing of levels of nesting and others.
Navigation Property Management: Users can now delete and add navigation properties, enabling the creation of one-way associations.
Improved Database Generation: SQL CE support has been added. In addition, customization of database generation is significantly simpler now, with the ability to specify the DDL generation template to be used, as well as automatic discovery of installed database generation workflows and templates.
New Extensibility APIs: New APIs enable users to add custom properties to any object in the model and have those properties show up in the property sheet. In addition, other extension points allow for customization of models on load, save, and after the model creation and update wizards run.
Generation of Complex Types from Stored Procedures: When creating a function import from a function, the UI can now detect the columns returned from a stored procedure and create a corresponding complex type. In addition, existing complex types can be updated when a stored procedure definition changes.
Greatly Improved Facet Management: The designer can now distinguish between empty and blank values, and various property facet defaults are handled more cleanly and consistently.
LINQ to Entities improvements: Support for recognizing additional patterns in queries, simplification of EntityFunctions and SqlFunctions static classes and OrderBy is now lifted over filters and other operations.

ADO.NET Data Services 4 Beta 2

Projections: This ADO.NET Data Services URI format has been extended to express projections (i.e. you can now work with a subset of the properties of an entity). Beta 2 includes both server and client library (including LINQ support) support for projections.
Data Binding: The data services client library for the .NET Framework 3.5 SP1 and Silverlight2 has been extended to support two-way data binding for WPF and Silverlight based applications.
Row Count: One scenario we heard a ton of feedback on after shipping V1 of ADO.NET Data Services in the .NET Framework 3.5SP1 is the ability for the a client of a data service to determine the total number of entities in a set without having to retrieve them all. To address this need, we have extended the data services addressing scheme to allow a client to obtain this type of information without having to download all the entities in a set.
Feed Customization (aka "Web Friendly Feeds"): A common ask we have received is to provide the ability to customize how entities are mapped into the various elements of an AtomPub feed. This feature does just that by providing a data service author declarative control over how the data service runtime maps the properties of an entity (e.g. a Customer, Order, etc) to the elements of a feed.
Server Driven Paging (SDP): This one is best described by example. If you had a data service that exposes photos, you likely want to limit the total number of photos a single request to the service can retrieve because the total collection of photos may be very large. This feature allows a service author to set per collection limits on the total number of entities returned for each request. In addition to limiting the number of photos returned per request, the server provides the client a "next link" which is simply a URI specifying how to continue retrieving the rest of the entities in the collection not returned by the first request. For those familiar with AtomPub, this feature adds support for AtomPub <link rel="next" ...> elements to the data service runtime.
Enhanced BLOB Support: This feature enhances the BLOB support provided in V1 to enable data services to stream arbitrarily large BLOBs, store binary content separate from its metadata, easily defer the loading of BLOB content when its metadata is requested, etc.
Request Pipeline: We have started to expose events throughout the data services server request processing pipeline. For this release we’ll expose request level events and in future we’ll look to expose more fine grained events based on your feedback. The goal of exposing our processing pipeline is to allow services further transparency into a data service such that a service author can do things such as setting HTTP response cache headers, wrapping interceptor processing and data service request processing in a single transaction, etc.
New "Data Service Provider" Interface for Custom Provider Writers: As the data services runtime has evolved, so has the number of ways people want to plug data into the data service framework. In V1, two methods (Entity Framework and arbitrary .NET classes) were supported to enable a data service to interact with various diverse data sources. To address another class of environments and data sources we have introduced a way to write a "custom" provider for those cases when the previous two provider models don't meet your needs.

Thank you,

Elisa Flasko
Program Manager,
Data & Modeling Group

POCO in the Entity Framework : Part 2 – Complex Types, Deferred Loading and Explicit Loading

dpblogs — Thu, 28 May 2009 19:03:00 GMT

In my post last week on the POCO Experience in Entity Framework, I covered the fundamentals of POCO support in Entity Framework 4.0. In this post, I’ll cover a few more aspects related to POCO.

Complex Types

Complex Types are supported in POCO just like they are with regular EntityObject based entities. All you have to do is declare your complex types as POCO classes and then use them for declaring the complex type based properties on your POCO entities.

As an example, here’s an InventoryDetail complex type to represent a part of my Product entity:

public class InventoryDetail
{
    public Int16 UnitsInStock { get; set; }
    public Int16 UnitsOnOrder { get; set; }
    public Int16 ReorderLevel { get; set; }
}

My Product class now has been modified to include a property of this type to group the inventory detail fields:

public class Product
{
    public int ProductID { get; set; }
    public string ProductName { get; set; }
    public int SupplierID { get; set; }
    public string QuantityPerUnit { get; set; }
    public decimal UnitPrice { get; set; }
    public InventoryDetail InventoryDetail { get; set; }
    public bool Discontinued { get; set; }
    public Category Category { get; set; }
}

You can then do everything you are used to doing with Complex Types. Here’s how I use it in a query:

var outOfStockProducts = from c in context.Products
                         where c.InventoryDetail.UnitsInStock == 0
                         select c;

As you can see, Complex Type support with POCO is really straightforward to use. There are a couple of things you need to keep in mind when using complex types support with POCO:

You must define your Complex Type as a class. Structs are not supported.
You cannot use inheritance with your complex type classes.

While we are on the topic of Complex Types, I thought I’d mention one other thing: Did you know that the Entity Framework designer in Visual Studio 2010 supports complex type declarations?

In Visual Studio 2008, you had to manually add the Complex Type declaration to the CSDL. That is all history with the Complex Type support in the designer in Visual Studio 2010.

And what’s cool is that because Visual Studio 2010 supports Multi-Targeting, you can use this capability when building applications that target .NET Framework 3.5, using Entity Framework 3.5 as well!

Deferred/Lazy Loading

In my sneak preview post on Deferred Loading two weeks ago, I mentioned that there is now Deferred Loading support in Entity Framework. It comes as no surprise then that the default code-generated entity types out of the box based on EntityObject will offer Deferred Loading. If you are wondering whether Deferred Loading is supported with POCO objects, then I think you will be happy to know that you can get Deferred Loading with POCO as well.

There are two things you need to do in order to get Deferred Loading support with POCO entities:

Declare the property that you would like to load lazily as virtual. These properties can be any collection type that implements ICollection<T> or they can be a reference representing a 1/0..1 relationship.

For instance, here’s a part of the updated Category entity class which I have modified to support Deferred Loading:

public class Category
{
    public int CategoryID { get; set; }
    public string CategoryName { get; set; }
    public string Description { get; set; }
    public byte[] Picture { get; set; }
    public virtual List<Product> Products { get; set; }
    ...

2. Enable deferred loading on the context:

context.ContextOptions.DeferredLoadingEnabled = true;

That’s it. You will now get automatic Deferred Loading for your POCO types without having to do anything else.

So how exactly does this work and what’s going on under the covers?

The reason why this works is because when I marked my collection property as virtual, this allowed the Entity Framework to provide a proxy instance for my POCO type at runtime, and it is this proxy that does automatic deferred loading. The proxy instance is based on a type that derives from my own POCO entity class - so all functionality you have provided is preserved. From a developer point of view, this allows you to write persistence ignorant code even when deferred loading might be a requirement.

If you were to inspect the actual instance in the debugger, you will see that the underlying type for the instance is different from the original type that I declared:

While the Entity Framework does its best to provide automatic deferred loading with minimal friction, this is something you need to be aware of when dealing with manual creation of instances that you want to then add or attach, or when you serialize/deserialize instances.

Manual instantiation of Proxy instances for POCO entities

In order to enable creation of proxy instances for adding/attaching, you can use the CreateObject factory method on ObjectContext for creating entity instances:

Category category = context.CreateObject<Category>();

Try to keep this in mind and use CreateObject when creating instances that you want to then use with the Entity Framework.

More Efficient Change Tracking with “Change Tracking Proxies”

The standard POCO entities we have talked about until now rely on snapshot based change tracking – i.e. the Entity Framework will maintain snapshots of before values and relationships of the entities so that they can be compared with current values later during Save. However, this comparison is relatively expensive when compared to the way change tracking works with EntityObject based entities.

There is another type of proxy that will allow you to get better performance out of change tracking with POCO entities.

If you are familiar with IPOCO, you know that IEntityWithChangeTracker was one of the interfaces you were required to implement to provide change notifications to the Entity Framework.

Change Tracking proxies subclass your POCO entity class to provide you with this capability during runtime without requiring you to implement the IPOCO interfaces yourself.

In many ways, you get the best of both worlds with this approach: You get persistence ignorance with POCO classes and you get the performance of EntityObject / IPOCO when it comes to change tracking.

To get change tracking proxies, the basic rule is that your class must be public, non-abstract or non-sealed. Your class must also implement public virtual getters/setters for all properties that are persisted. Finally, you must declare collection based relationship navigation properties as ICollection<T> only. They cannot be a concrete implementation or another interface that derives from ICollection<T> (a difference from the Deferred Loading proxy)

Here’s an example of my POCO class for Product that will give me more efficient proxy based change tracking at runtime:

public class Product
{
    public virtual int ProductID { get; set; }
    public virtual string ProductName { get; set; }
    public virtual int SupplierID { get; set; }
    public virtual string QuantityPerUnit { get; set; }
    public virtual decimal UnitPrice { get; set; }
    public virtual InventoryDetail InventoryDetail { get; set; }
    public virtual bool Discontinued { get; set; }
    public virtual Category Category { get; set; }
}

Once again, keep in mind that you must use CreateObject for creating proxy instances you want to then add or attach to the context. But pure POCO entities that don’t rely on proxies and proxy based entities can work together. You need to only use CreateObject when dealing with proxy based entities.

What if I want both Deferred Loading and better change tracking for the same POCO type?

The two are not mutually exclusive and you don’t have to choose between a Deferred Loading proxy and a Change Tracking proxy. If you want Deferred Loading and efficient change tracking, you just have to follow the rules for Change Tracking via proxies, and enable Deferred Loading. Change Tracking proxies will give you deferred loading if deferred loading is enabled.

Explicit Loading

All this deferred loading capability is great – but there are plenty of you out there that want to be in full control of how you load related entities. You might even choose to go the route of pure POCO without having to resort to any of the automatic proxy generation done for you.

This is a perfectly acceptable (and preferable in many cases) and you can use explicit loading of relationships and be in complete control of how you query for data from the database.

There are two options for doing Explicit Load with POCO:

One is to use ObjectContext.LoadProperty and specify the name of the navigation property you want to load:

context.LoadProperty(beveragesCategory, "Products");

This gets the job done – but it isn’t very type safe as you can see. If I don’t have the right name of the navigation property here, I will get a runtime exception.

Some of you might actually prefer this:

context.LoadProperty(beveragesCategory, c => c.Products);

I can use a lambda expression to specify the property that I want to load explicitly, and this is offers more type safety.

So that’s about everything I planned on covering in the second post. There’s more to come however – in the final part of this series, we’ll go over some of the things to be aware of when dealing with pure POCO (non proxy) instances and keeping things in sync between your object graph and the Object State Manager. We will also cover variations of SaveChanges that you might want to be aware of.

In the meantime, check out the sample code that I have updated to cover some of the things we have talked about in this post.

Faisal Mohamood
Program Manager, Entity Framework

DataSet and Silverlight

dpblogs — Wed, 27 May 2009 07:41:00 GMT

I’ve been asked a few times lately whether DataSet is or will be supported in Silverlight, so I thought I’d post the answer here.

There are no plans to add DataSet into future releases of Silverlight. However we are investigating work to bridge existing DataSet investments to new data technologies. Below are three different approaches that can be used to build data-centric applications in Silverlight now.

ADO.NET Data Services is the primary approach to creating data-centric applications in Silverlight. There is a client api within Silverlight for accessing these RESTful Services. ADO.NET Data Services exposes data through ATOM and JSON which are standard technologies when building rich internet applications. Here is a link to get started on this technology: http://msdn.microsoft.com/en-us/data/bb931106.aspx.

In addition to ADO.NET Data Services, there is .Net RIA Services. The project aims to allow developers to build rich internet applications on Silverlight using Visual Studio. This isn't a released project yet, but there May 2009 preview that developers can use. Here is a link to this preview: http://silverlight.net/forums/53.aspx.

Lastly, if there are requirements to expose data through Web Services rather than RESTful Services, we would recommend using WCF. These services can be accessed within Silverlight and would expose specific data contracts, not DataSets. Here is a link to get started on this approach: http://msdn.microsoft.com/en-us/magazine/cc794260.aspx. We welcome any feedback from the community on this.

Thanks,
Chris Robinson
Program Manager - DataSet

Entity Framework-Enabled Providers Lists

dpblogs — Mon, 26 Jan 2009 23:05:00 GMT

I love posting announcements to the blog to let people know about the latest and greatest information about Entity Framework-enabled ADO.NET providers. Blogs are perfect for announcements like that, but they're not as handy for providing an overview about the available Entity Framework-enabled providers.

To help customers quickly and easily see what Entity Framework-enabled providers are available, released providers are listed on the main Entity Framework page here. We also have a separate page that lists all publicly available providers, including pre-released providers here.

We'll continue to post announcements about provider availability to the team blog. The corresponding entries will appear on the provider list pages within a couple days, since those changes require more time to format and review.

David Sceppa
ADO.NET Program Manager

OpenLink Releases Their Virtuoso ADO.NET Entity Framework Provider

dpblogs — Tue, 13 Jan 2009 04:20:00 GMT

It is my pleasure to announce that OpenLink Software has released their Virtuoso ADO.NET Entity Framework provider - an ADO.NET 3.5 data provider compatible with Visual Studio 2008 and Entity Frameworks, that provides access to native Virtuoso data (SQL, XML, and RDF) in addition to any Virtuoso Linked Tables from external ODBC and JDBC accessible data sources. Known-compatible external data sources include Oracle (versions 7.x to 11.x), Microsoft SQL Server (6.x to 2005), IBM DB2 , Sybase (4.2 to 12.x+), IBM Informix (5.x to 11.x), Ingres (6.4 to 9.x), Progress (7.x to 10.x), MySQL, PostgreSQL, and Firebird.

For more information, see the OpenLink announcement page about the release here. Congratulations to everyone at OpenLink who contributed to the release!

Enjoy!

David Sceppa
ADO.NET Program Manager

Beta of Firebird ADO.NET Provider with Entity Framework Support Available

dpblogs — Tue, 13 Jan 2009 03:52:00 GMT

I'm pleased to announce that a beta of the Firebird ADO.NET provider with Entity Framework support is now available. Congratulations to Jiří Činčura and to everyone else who has worked on this project so far!

For more information, please see Jiří's blog post here or access the download page for the provider here.

Enjoy!

David Sceppa
ADO.NET Program Manager

IBM's ADO.NET Provider Supports the Entity Framework!

dpblogs — Thu, 11 Dec 2008 03:57:00 GMT

Time for another update on Entity Framework-enabled ADO.NET providers.

It is my pleasure to announce that IBM has added Entity Framework support to their ADO.NET provider. The provider supports DB2, Informix and U2 databases. For more information on the specific versions of the IBM data servers supported, see this page on the IBM web site.

Congratulations to everyone at IBM who contributed to the release, and a special thanks to Brent Gross and Praveen Ghantasala for all of the feedback they provided back to the Entity Framework team!

Enjoy!

David Sceppa
ADO.NET Program Manager

“Table Splitting”: Mapping multiple entity types to the same table.

dpblogs — Sat, 06 Dec 2008 02:25:00 GMT

Imagine that you have a table called “Products” which contains a number of columns holding a large amount of data. For example, images of the product from above, front, and side. For most operations against instances of Products, you do not wish to pull down these large columns.

Or, imagine that you would like to split a table such that some clients get a constrained view of the table, while more sophisticated clients get additional information, such as auditing and other internal fields.

There are several ways with which to accomplish this in the Entity Framework, but one of the more flexible and powerful approaches is not much discussed. In this blog post, I will provide a soup-to-nuts example, from DDL to client code, of how to implement this pattern.

Step 1: Create the Sample Database

We’ll start with an example table, although any table will do:

CREATE TABLE [dbo].[Products](
                [id] [int] IDENTITY(1,1) NOT NULL,
                [Name] [nvarchar](150) NOT NULL,
                [MSRP] [money] NOT NULL,
                [FrontImage] [image] NOT NULL,
                [TopImage] [image] NOT NULL,
                [SideImage] [image] NOT NULL,
 CONSTRAINT [PK_Products] PRIMARY KEY CLUSTERED 
(
                [id] ASC
)WITH (PAD_INDEX  = OFF, IGNORE_DUP_KEY = OFF) ON [PRIMARY]
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]
END

I created this table in a database schema called “TableSplitting”

Step 2: Create the Entity Data Model

I created a new command-line project and added an Entity Data Model file to it called “TableSplitting.edmx”. I used the wizard to reverse engineer the database containing the Products table defined above, which resulted in this model:

Step 3: Modify the Model

1. Rename “Products” to “Product”.

2. Copy and paste the “Product” type and rename the copied type “ProductImages”.

3. Delete “FrontImage”, “TopImage” and “SideImage” from “Product”.

4. Delete “Name” and “MSRP” from “ProductImages”.

5. Add a 1:1 association between “Product” and “ProductImages”.

The resulting model should look like this:

Step 4: Map the Model

The mappings for the ProductImages type should look like this:

The mappings for the association should look like this:

Step 5: Introduce a Referential Constraint

At this point we have one remaining problem: If you build the project, you will get the following error:

Error 3021: Problem in Mapping Fragment starting at line 72: Each of the following columns in table Products is mapped to multiple conceptual side properties: Products.id is mapped to <ProductsProductImages.ProductImages.id, ProductsProductImages.Products.id>

Fixing this duplicate mapping issue requires a referential constraint, which the designer will only support in the next release, so save the edmx file, close it, then right-click it in Solution Explorer, select “Open With…” and double click on “XML Editor”.

In the CSDL section, you will see the ProductProductImages association:

<!-- CSDL content -->
…
<Association Name="ProductProductImages">
  <End Type="TableSplittingModel.Product" Role="Product" Multiplicity="1" />
  <End Type="TableSplittingModel.ProductImages" Role="ProductImages" Multiplicity="1" />
</Association>
 
We add the referential constraint to it to inform the model that the ids of these two types are tied to each other:
 
<Association Name="ProductProductImages">
  <End Type="TableSplittingModel.Product" Role="Product" Multiplicity="1" />
  <End Type="TableSplittingModel.ProductImages" Role="ProductImages" Multiplicity="1" />
  <ReferentialConstraint>
    <Principal Role="Product"><PropertyRef Name="id"/></Principal>
    <Dependent Role="ProductImages"><PropertyRef Name="id"/></Dependent>
  </ReferentialConstraint>
</Association>

At this point, the model should validate when you build your project.

Step 6: Test the Model

Finally, we’ll write some code that will create a product and its images, then pull the product back and lazily load its images. The acquisition of test images for the front, side, and top is left as an exercise for the user.

static void Main(string[] args)
{
      Product product = new Product() {
            Name = "Split Entity Soup",
            MSRP = 1337.42M,
      };
      ProductImages productImages = new ProductImages();
      product.ProductImages = productImages;
      productImages.FrontImage = File.ReadAllBytes(@"C:\front.jpg");
      productImages.SideImage = File.ReadAllBytes(@"C:\side.jpg");
      productImages.TopImage = File.ReadAllBytes(@"C:\top.jpg");
 
      //Save a product with its images
      using (TableSplittingEntities context = new TableSplittingEntities()) {
            //Adding the product also implicitly adds the product's images object.
            context.AddToProductSet(product);
            context.SaveChanges();
            Console.Out.WriteLine("Saved product {0}.", product.id);
            //Note that productImages.id is the same as product.id. This is why we love the Entity Framework.
            Console.Out.WriteLine("Saved product images {0}.\n", productImages.id);
      }
 
      //Next, the product, update it, then load its images
      using (TableSplittingEntities context = new TableSplittingEntities()) {
            //Query the product back from the database
            product = (from p in context.ProductSet
                           where p.id == product.id
                           select p).FirstOrDefault();
            //Note that product.ProductImages is null, since we did not include it in the query
            Console.Out.WriteLine("Retrieved product {0} with product images '{1}'.", product.id, product.ProductImages);
 
            //We can now lazily load the product's images
            product.ProductImagesReference.Load();
            Console.Out.WriteLine("Retrieved product images for product {0}.", product.ProductImages.id);
            Console.Out.WriteLine("Retrieved product front product image contains {0} bytes.", product.ProductImages.FrontImage.Length);
            Console.Out.WriteLine("Retrieved product side product image contains {0} bytes.", product.ProductImages.SideImage.Length);
            Console.Out.WriteLine("Retrieved product top product image contains {0} bytes.", product.ProductImages.TopImage.Length);
            Console.ReadLine();
 
      }
}

Running this code will result in output that looks something like this:

Saved product 8.

Saved product images 8.

Retrieved product 8 with product images ''.

Retrieved product images for product 8.

Retrieved product front product image contains 31345 bytes.

Retrieved product front product image contains 45332 bytes.

Retrieved product front product image contains 98761 bytes.

A Note About Optimistic Concurrency

In a timestamp-based optimistic concurrency model, the timestamp column can only be mapped to one of the types. Placing the timestamp on the Product type (and setting its ConcurrencyMode to “fixed”) means that if you alter an instance of ProductImage and call SaveChanges() and then alter Product and call SaveChanges() again, you will get an optimistic concurrency exception. This is not a “strong” guarantee that the two types are written to the database as a unit, but can be helpful. If you desire to have optimistic concurrency guarantees against both types, a more careful, manual process is probably necessary, for example, the creation of integer “ProductVersion” and “ProductImagesVersion” columns that are updated manually.

A Note About Possible Issues

There is a bug in the current mapping system that may cause validation errors when using this technique in some situations. We are fixing this issue for the next release. In the meantime, validation issues are most often resolved by reversing the principal and dependent roles in the referential constraint.

We hope you’ve found this post useful and look forward to your feedback.

Thank you,

The Entity Framework Team

Update on LINQ to SQL and LINQ to Entities Roadmap

dpblogs — Thu, 30 Oct 2008 03:36:00 GMT

Since the release of LINQ to SQL and the Entity Framework, many questions have been raised about the future plans for the technologies and how they will relate to each other long term.
During this week of PDC we are now at a point, with the announcement of Visual Studio 10 and the .NET Framework 4.0, that we can provide more clarity on our direction.

We have seen great momentum with LINQ in the last year. In .NET Framework 3.5 we released several LINQ providers, including LINQ to SQL which set the bar for a great programming model with LINQ over relational databases. In .NET 3.5 SP1, we followed up that investment with the Entity Framework enabling developers to build more advanced scenarios and to use LINQ against any database including SQL Server, Oracle, DB2, MySQL, etc.

We’re making significant investments in the Entity Framework such that as of .NET 4.0 the Entity Framework will be our recommended data access solution for LINQ to relational scenarios. We are listening to customers regarding LINQ to SQL and will continue to evolve the product based on feedback we receive from the community as well.

Tim Mallalieu
Program Manager, LINQ to SQL and Entity Framework

Sybase's SQL Anywhere ADO.NET Provider Supports the ADO.NET Entity Framework!

dpblogs — Tue, 21 Oct 2008 21:13:00 GMT

Another Entity Framework-enabled ADO.NET providers post! Woohoo!

It is my pleasure to announce that as part of the release of SQL Anywhere 11, Sybase iAnywhere has added Entity Framework support to their ADO.NET provider. For more information on the SQL Anywhere 11 release, please see the following announcement on the Sybase web site:

http://www.sybase.com/detail?id=1057559

Congratulations to everyone else at Sybase who contributed to the release!

Enjoy!

David Sceppa

ADO.NET Program Manager

Introducing Table-Valued Parameters - Part 1

dpblogs — Sat, 16 Aug 2008 02:37:53 GMT

Hey everyone!

I am Himanshu. I am a program manager in the ADO.Net team. Today I am going to talk about Table-Valued parameters that are new in SQL Server 2008. About 4 years back I was writing an application which involved adding metadata about my music library into a database. The database had a table each for storing Artists, Albums, and Songs. While adding an Album of songs into the database I had to insert data into each of these tables. I had defined stored procedure for inserting data into each of the tables. In the first iteration there was a bug in the code due to which these operations were not being done in a single transaction. Needless to say this bug surfaced as a data-corruption issue later on. Once identified the fix was trivial, ensure that all commands are executed in a single transaction. However, what I would have really liked to do was to be able to call a single stored procedure to which I could pass the metadata about the Album and the list of songs at the same time. But there was no good way of accomplishing this back then. I was programming against SQL Server 2000 back then. I am excited to say that now with the new table-valued parameters in SQL Server 2008 I can finally write a single stored procedure that will let me accomplish this without any kind of hacks!

Table-Valued parameters, as the name suggests lets you pass a table as parameter to a stored procedure. In order to use table-valued parameters you need to define a table type and then use the table type in the definition of the stored procedure. Let me illustrate this with the help of an example. I am going to first create a table type named Songs_TableType with two columns, Title and TrackNumber. Then I will use it in a stored procedure to pass a table as parameter.

First creating the table type

Create Type Songs_TableType as Table
(Title nvarchar(120) not null,
TrackNumber int)

I can now use this type in a stored procedure to pass a table as a parameter. The following T-Sql shows how to define a stored procedure that takes this type as a parameter. Note that I have skipped error handling for brevity.

create procedure AddSongs(
 @ArtistName nvarchar(120), 
 @AlbumName nvarchar(120), 
 @Songs Songs_TableType READONLY)
as
begin
 -- Add the Artist
 Declare @ArtistID int
 insert into Artists values (@ArtistName)
 select @ArtistID = SCOPE_IDENTITY()

 -- Add the Album
 Declare @AlbumID int
 insert into Albums values (@AlbumName, @ArtistID)
 select @AlbumID = SCOPE_IDENTITY()

 -- Insert songs
 insert into Songs 
 select title, trackNumber, @AlbumID, @ArtistID
 from @Songs
end

In the next post I will go into more details into how I can use the stored procedure defined above to simplify the code I have on the client. Till then, adios!

Himanshu Vasishth
Program Manager
ADO.NET

Entity Framework RTM Breaking Changes

dpblogs — Tue, 12 Aug 2008 21:44:00 GMT

There were a number of changes to the Entity Framework and the designer between Visual Studio 2008 SP1/ .NET Framework 3.5 Beta and RTM that will require updates to existing source code. These breaking changes are listed below, including the mitigation for adjusting to the new behavior, and a side by side comparison of Beta code and RTM code.

Jeff Derstadt
Entity Framework Developer

Provider Changes

1. The Function property of DbFunctionCommandTree is renamed to EdmFunction.
Affects:
- Provider writers

Mitigation:
- Replace ".Function" wtih ".EdmFunction"

SP1 Beta Code:

funcTree.Function

SP1 RTM Code:

funcTree.EdmFunction

2. DbExpression, DbAggregate and DbModificationClause no longer have 'CommandTree' property

Affects:
- Provider writers

SP1 Beta Code:
Provider writers were able to go directly from an expression to a command tree, so when visiting a command tree in CreateDbCommandDefinition, the expression instance was enough to have.

public DbCommandDefinition CreateDbCommandDefinition(
DbProviderManifest manifest, 
DbCommandTree commandTree)
{
    commandTree.Validate();
    DbQueryCommandTree queryTree = (DbQueryCommandTree)commandTree;
    string tsql = this.Visit(queryTree.Query);
    return new CustomCommandDefinition(queryTree.Parameters, tsql);
}
 
...
 
public override string VisitParameterReferenceExpression(
DbParameterReferenceExpression expression)
{
    if (!expression.CommandTree.Parameters.ToDictionary(p => p.Key, p => p.Value).ContainsKey(expression.ParameterName))
    {
       throw new ArgumentException("Invalid parameter name");
    }
 
    return "@" + expression.ParameterName;
}

SP1 RTM Code:
Providers must now keep a reference to the command tree that was passed as an argument to CreateDbCommandDefinition if they need to refer back to it.

private DbCommandTree _currentTree;

public DbCommandDefinition CreateDbCommandDefinition(
DbProviderManifest manifest, 
DbCommandTree commandTree)
{
// no need to call commandTree.Validate()  
 // EF has already done so and the tree cannot change
DbQueryCommandTree queryTree = (DbQueryCommandTree)commandTree;
this._currentTree = commandTree;
string tsql = this.Visit(queryTree.Query);
return new CustomCommandDefinition(queryTree.Parameters, tsql);
}

...

public override string VisitParameterReferenceExpression(
DbParameterReferenceExpression expression)
{
if (!this._currentTree.Parameters.ToDictionary(p => p.Key, p => p.Value).ContainsKey(expression.ParameterName))
{
throw new ArgumentException("Invalid parameter name");
}

return "@" + expression.ParameterName;
}

3. DbCommandTree.Validate method is removed

Affects:
- Provider writers

4. DbCommandTree and DbExpression no longer have a Clone method

Affects:
- Provider writers

SP1 Beta Code:
Provider writers were previously able to clone a command tree or a expression, e.g:

DbCommandTree tree = ...
DbCommandTree clonedTree = tree.Clone();

DbQueryCommandTree queryTree = ...
DbExpression clonedExpression = queryTree.Query.Clone();

SP1 RTM Code:
Providers will no longer be able to clone a DbCommandTree or a DbExpression

5. DbNaryExpression is removed from the CommandTree API

Affects:
- Provider Writers

Workaround:
- Use DbArithmeticExpression

SP1 Beta Code:

IList<DbExpression> arg = ((DbNaryExpression)exp).Arguments;

SP1 RTM Code:

IList<DbExpression> arg = ((DbArithmeticExpression)exp).Arguments;

6. ProviderManifest.Provider and ProviderManifest.Token properties have been removed

Affects:
- Provider Writers

SP1 Beta Code:

protected override DbCommandDefinition CreateDbCommandDefinition(
DbProviderManifest providerManifest,
DbCommandTree commandTree)
{     
  if(!SqlProviderManifest.ProviderInvariantName.Equals(
     providerManifest.Provider, StringComparison.Ordinal))
  {
   throw EntityUtil.Argument(...);
  }
 
  ...
 
}

SP1 RTM Code:

protected override DbCommandDefinition CreateDbCommandDefinition(
DbProviderManifest providerManifest,
DbCommandTree commandTree)
{     
  if(!(providerManifest is SqlProviderManifest))
  {
   throw EntityUtil.Argument(...);
  }
 
  ...
 
}

7. DbFunctionExpression IsLambda and LambdaBody properties are now internal

Affects:
- Provider Writers

SP1 Beta Code:
In provider code it was possible to inspect the values of the IsLambda and Lambda body parameters, but they would always be false and null, respectively.

protected override void VisitDbFunctionExpression(
DbFunctionExpression expression)
{ 
if(expression.IsLambda) {
throw EntityUtil.NotSupported(...);
}

GenerateFunctionInvocationSql(expression);
}

SP1 RTM Code:
Any code that was testing the values of these properties is unnecessary.

protected override void VisitDbFunctionExpression(
DbFunctionExpression expression)
{ 
GenerateFunctionInvocationSql(expression);
}

Entity Services Changes

1. The Metadata keyword in an entity connection string is now required.

Affects:
- EntityConnection and ObjectContext users

SP1 Beta Behavior:
In SP1 Beta, initializing an EntityConnection with a connection string that that doesn't have a Metadata keyword would not throw on the ConnectionString setter or constructor, but would throw on calls to Open() and GetMetadataWorkspace().

SP1 RTM Behavior:
In SP1 RTM, the EntityConnection will throw in the ConnectionString setter or constructor.

2. EntityDataReader no longer overrides Object.GetHashCode() and Object.Equals(Object object)

Affects:
- EntityDataReader users

SP1 Beta Code:
Object.Equals(Object object)

Users could have compared two data readers for equality.

Object obj = …
EntityDataReader reader = …

reader.Equals(obj);

Object.GetHashCode()

Users could have used instances of EntityDataReader as keys in data structures relying on hashing algorithms such as a hash table or a dictionary.

System.Collections.Hashtable hashtable = new Hashtable();
EntityDataReader reader1 = …
hashtable.Add(reader1, "first");

SP1 RTM Code:
Object.Equals(Object object)

Unchanged, but the result would be based on the default implementation.

Object.GetHashCode()

The default implementation of GetHashCode does not guarantee unique return values for different objects. Thus while the same code would run, it would be officially not supported.

Mapping and Metadata Changes

1. Compile time view generation hash has changed

Affects:
- Users of compile time view generation

Mitigation:
- Anyone who uses compile time view generation will need to regenerate the views and recompile
them.

2. SSDL no longer allows periods in Entity, Association, EntityContiner, EntitySet, AssociationSet, and Function names

Affects:
- Metadata artifact authors

Mitigation:
- Names need to be changed so that they do not include periods

SP1 Beta Code:

<EntityType Name="Entity.1">
...
</EntityType>
<EntityContainer Name="Entity.Container">
 <EntitySet Name="Entity.1"
             Entity="My.Namespace.[Entity.1]"/>
</EntityContainer>

SP1 RTM Code:

<EntityType Name="Entity_1">...</EntityType><EntityContainer Name="Entity_Container"> <EntitySet Name="Entity_1" Table="Entity.1"
             Entity="My.Namespace.Entity_1"/></EntityContainer>

3. MetadataException constructors no longer take DataSpace string

Continue to use the following constructors to construct MetadataException.

public MetadataException(string message)
public MetadataException(string message, Exception innerException)

EntityDataSource Changes

1. The IncludePaths property has been renamed to Include

Affects:
- ASP.NET users

SP1 Beta Code:
The property IncludePaths was used to specify which navigation propreties should be included in the query.

SP1 RTM Code:
The property name has changed to “Include”.

2. Public Methods removed from the EntityDataSourceView class

The following methods were removed from the EntityDataSourceView class

public String DefaultOrderByClause { get; }
public void DisposeContext();
public static Boolean EnumerableContentEquals( IEnumerable enumerableA,  IEnumerable enumerableB);

3. Event argument class APIs have changed

The event argument classes for the EntityDataSource have been re-architected to provide better usability.

Affects:
ASP.NET users

ContextCreating

SP1 Beta Code:

public class EntityDataSourceContextEventArgs : EventArgs
{
 // Methods
 public EntityDataSourceContextEventArgs();

 // Properties
 public ObjectContext Context { get; set; }
}

SP1 RTM Code:

public class EntityDataSourceContextCreatingEventArgs : EventArgs
{
 public ObjectContext Context { get; set; }
}

ContextCreated

SP1 Beta Code:

public class EntityDataSourceStatusEventArgs : EventArgs
{
}

SP1 RTM Code:

public class EntityDataSourceContextCreatedEventArgs : EventArgs
{
  public ObjectContext Context { get; }
}

ContextDisposing

SP1 Beta Code:

public class EntityDataSourceDisposeEventArgs : CancelEventArgs
{
 public object Context { get; }
}

SP1 RTM Code:

public class EntityDataSourceContextDisposingEventArgs : CancelEventArgs
{
 public ObjectContext Context { get; }
}

Selecting

SP1 Beta Code:

public class EntityDataSourceSelectEventArgs : CancelEventArgs
{
 public DataSourceSelectArguments Arguments { get; }
 public ParameterCollection CommandParameters { get; }
 public string CommandText { get; set; }
 public ObjectContext Context { get; }
 public string OrderBy { get; }
 public ParameterCollection OrderByParameters { get; }
 public string Where { get; }
 public ParameterCollection WhereParameters { get; }
}

SP1 RTM Code:

public class EntityDataSourceSelectingEventArgs : CancelEventArgs
{
 public EntityDataSource DataSource { get; }
 public DataSourceSelectArguments SelectArguments { get; }
}

Selected

SP1 Beta Code:
See EntityDataSourceStatusEventArgs

SP1 RTM Code:

 public class EntityDataSourceSelectedEventArgs : EventArgs
{
    public ObjectContext Context { get; }
 public Exception Exception { get; }
 public bool ExceptionHandled { get; set; }
 public IEnumerable Results { get; }
 public DataSourceSelectArguments SelectArguments { get; }
 public int TotalRowCount { get; }
}

Updating

SP1 Beta Code:

public class EntityDataSourceUpdateEventArgs : CancelEventArgs
{
 public Exception Exception { get; }
 public bool ExceptionHandled { get; set; }
 public object NewEntity { get; }
 public object OriginalEntity { get; }
}

SP1 RTM Code:

public class EntityDataSourceChangingEventArgs : CancelEventArgs
{
  public ObjectContext Context { get; }
 public object Entity { get; }
 public Exception Exception { get; }
 public bool ExceptionHandled { get; set; }
}

Updated

SP1 Beta Code:
See EntityDataSourceStatusEventArgs

SP1 RTM Code:

public class EntityDataSourceChangedEventArgs : EventArgs
{
 public ObjectContext Context { get; }
 public object Entity { get; }
 public Exception Exception { get; }
 public bool ExceptionHandled { get; set; }
}

Inserting

SP1 Beta Code:

public class EntityDataSourceInsertEventArgs : CancelEventArgs
{
 public Exception Exception { get; }
 public bool ExceptionHandled { get; set; }
 public object NewEntity { get; set; }
 public IDictionary Values { get; }
}

SP1 RTM Code:
See EntityDataSourceChangingEventArgs

Inserted

SP1 Beta Code:
See EntityDataSourceStatusEventArgs

SP1 RTM Code:
See EntityDataSourceChangedEventArgs

Deleting

SP1 Beta Code:

public class EntityDataSourceDeleteEventArgs : CancelEventArgs
{
 public EntityDataSourceValidationException Exception { get; }
 public bool ExceptionHandled { get; set; }
 public object OriginalEntity { get; }
}

SP1 RTM Code:
See EntityDataSourceChangingEventArgs

Deleted

SP1 Beta Code:
See EntityDataSourceStatusEventArgs

SP1 RTM Code:
See EntityDataSourceChangedEventArgs

Tools Changes

1. Namespace generation has changed

Existing EDMX files will be affected as soon as you make a change, open/save/close it, “Run Custom Tool” or move the EDMX file into a project sub-folder.

In SP1 beta the data classes were generated into a separate top level CSDL model namespace and users were forced to import the CLR namespace or fully qualify the class names in order to consume the generated data classes. The following changes were made in the RC based on feedback from users:

The Model Namespace specified in the wizard GUI has nothing to do with the CLR namespace of the generated data classes
The data classes are generate into a CLR namespace determined by the Visual Studio project system (based project type and the project sub-folder containing the EDMX file)
The designer respects the value of the Custom Tool Namespace project item property (if set)

Note: EDMX files in VB projects with an empty root namespace or in App_Code root in ASP.NET website projects continue to have the Beta 1 behavior for generated classes (i.e. data classes are generated into a separate top level CSDL model namespace)

Code consuming the model is affected as follows:

VB projects with an empty root namespace and ASP.NET website apps with EDMX files in App_Code root: no change since SP1 beta

All other projects where the EDMX file is in the project root:

a. SP1 Beta C# code example:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using NorthwindModel;

namespace ConsoleApplication1
{
 class Program
 {
 static void Main(string[] args)
 {
 using (NorthwindEntities entities = 
                       new NorthwindEntities())
 {
 foreach (Customers c in entities.Customers)
 Console.WriteLine(c.ContactName);
 }
 }
 }
}

b. SP1 RTM C# code example (note we don’t need the “using NorthwindModel;” anymore):

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace ConsoleApplication1
{
 class Program
 {
 static void Main(string[] args)
 {
 using (NorthwindEntities entities = 
                       new NorthwindEntities())
 {
 foreach (Customers c in entities.Customers)
 Console.WriteLine(c.ContactName);
 }
 }
 }
}

SP1 RTM C# code example for all projects where the EDMX file is in a project sub-folder (e.g. MyModels). Note the “using ConsoleApplication1.MyModels;” below:

PrFont34Bin0BinSub0Frac0Def1Margin0Margin0Jc1Indent1440Lim0Lim1using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using ConsoleApplication1.MyModels;

namespace ConsoleApplication1
{
 class Program
 {
 static void Main(string[] args)
 {
 using (NorthwindEntities entities = 
                 new NorthwindEntities())
 {
 foreach (Customers c in entities.Customers)
 Console.WriteLine(c.ContactName);
 }
 }
 }
}

In all projects, multiple EDMX files in the same project sub-folder cannot have duplicate entity or container names. Conflicts in generated classes (if any) can be resolved in one of the following ways:

a. For C# projects: Move the EDMX files into different project sub-folders folders or set the “Custom Tool Namespace” to a unique namespace

b. For ASP.NET website projects: Move the EDMX files into different project sub-folders folders under App_Code

c. For VB projects: Set the “Custom Tool Namespace” to a unique namespace

Update Model – a Question of Identity – Part 2 of 3

dpblogs — Tue, 22 Jul 2008 19:23:00 GMT

This article is Part 2 of 3 – please see http://blogs.msdn.com/adonet/archive/2008/07/21/update-model-a-question-of-identity-part-1-of-3.aspx for Part 1.

In the last article I explained the principle that the C-side updates would be non-destructive.

The “Update Model” code needs to decide when we should add new C-side EntityTypes, new C-side Properties and new C-side Associations. This brings us into the idea of identity. Bear with me – this can get pretty complicated.

Suppose you have a database with two tables in it. They have the same name but are in different schemas e.g. schema1.Customer and schema2.Customer. All S-side EntitySets (which are the way the EDM represents a database table or view) in a given model must have unique names. So if you attempt to import both of the above tables then one of them will be represented as an EntitySet with name ‘Customer’ and one with name ‘Customer1’ each with a matching EntityType. Which one will be which? Well, it depends on in what order you import them and sometimes on what else you import at the same time. The important point is that the Name attribute of the EntitySet is not always the same as the name of underlying database object.

So we cannot rely on the Name attribute of a given EntitySet to identify the underlying database object. But for “Update Model from Database” we do need to identify what the true underlying database object is to decide whether a given one is “new”. So instead we construct a “database identity” for each S-side EntitySet which consists of its underlying schema name and its underlying table/view name. If the EntitySet’s Name attribute does not match the underlying table/view name then either a Table attribute or the special attribute store:Name (where ‘store’ is a prefix defined as the XML namespace “http://schemas.microsoft.com/ado/2007/12/edm/EntityStoreSchemaGenerator”) is defined on that EntitySet. The value of this attribute is the true underlying database object name. Similarly the Schema or store schema attribute will represent the true underlying database schema name (and there’s a similar story for Function elements which is how the EDM represents stored procedures).

This combination of the true database schema name and the true database object name are the “database identity” of that EntitySet. “New” S-side EntitySets are defined as those whose “database identity” does not appear in the S-side of the existing model.

For every imported, new S-side EntitySet we create a single, matching C-side EntitySet and EntityType and the mappings necessary to map them through to the S-side EntitySet. If it is available, we will use the existing S-side name for the matching C-side EntityType, but that name may already be in use in which case we will try appending 1, 2, 3 … until we find a name that is not in use.

So as an example, if a C-side EntityType, say ‘Customer’, was originally mapped to the S-side ‘Customer’ EntityType but has been manually unmapped, and “Update Model from Database” is run then the above rules will _not_ result in a “duplicate” C-side EntityType called ‘Customer1’ because “Update Model” knows that there was already a ‘Customer’ S-side EntityType – we assume the user knew what s/he was doing when they unmapped the C-side EntityType. However if a _new_ S-side EntityType called ‘Customer’ is added and there happens to exist a C-side EntitySet already called ‘Customer’ then the new, matching C-side EntityType would be called ‘Customer1’ and it will be up to the user to rename the C-side EntityTypes as needed.

In the next article I’ll explain how this concept is extended to C-side Properties and Associations.

Lawrence Jones
Software Design Engineer, Entity Framework Tools

Update Model – a Question of Identity – Part 1 of 3

dpblogs — Mon, 21 Jul 2008 21:01:00 GMT

I propose to explain the reason behind some of the oddities of the “Update Model from Database” functionality and hopefully answer some common questions that come up about it.

Before I get started let me note that this will be a fairly technical post split into three parts (I’ll post links to the other parts as responses to this one). There is also a good blog on this subject taking a look at the changes since our last release and showcasing some particular examples of the principles I will be explaining below. This blog is by Noam Ben-Ami at the following link: http://blogs.msdn.com/adonet/archive/2008/04/01/update-model-from-db.aspx.

An EDMX file represents the conceptual (C-) side of the model, the storage (S-) side of the model and a mapping between the two. The major job of “Update Model from Database” is to update the S-side of the model to be consistent with any changes that have been made to the database since it was created or last updated. (Note that in this sense “changes” can also include any database objects which you chose not to include in your S-side model the last time through). “Update Model” will also automatically remove any mappings which would target non-existent S-side objects after the update.

For RTM, the S-side of the model is completely replaced by a new S-side model generated from all the tables/views/stored procedures in the existing model plus any new ones selected via the “Update Model from Database” wizard. This has the advantage of ensuring that the new S-side model is self-consistent, but has the disadvantage that it removes any S-side elements which have been added by hand to the EDMX file. We are considering alternatives to this approach for V2.

Now before we go on note that the Entity Designer shows you only the C-side of your model, not the S-side. The S-side is only visible through the Browser and entries in the Mapping Details window. Hence most people’s view of “the model” is the C-side of the model.

Note also that for any given S-side model there are many possible C-side models which could be mapped to it: in particular in addition to the more simple 1:1 scenario, two or more C-side EntityTypes can be mapped to the same underlying table, or a single C-side EntityType can be mapped to more than one table.

Although the major job of “Update Model from Database” is to update the S-side, we decided that, in order to reduce work for the user, we would also update the C-side but only under the following rule:

· The C-side updates would be non-destructive.

This means that we feel free to e.g. add new C-side EntityTypes to represent new S-side EntityTypes or new C-side Properties to represent new S-side Properties, but we will not e.g. delete a C-side EntityType because we believe the S-side EntityType it was mapped to has been deleted. Nor will we “resurrect” a C-side EntityType which the user has chosen to delete. We leave such decisions up to the user.

As a consequence of this it is possible that an Entity Data Model which passed validation before “Update Model” was run will no longer be valid after “Update Model” is run. In this case the user should investigate each error message in the Error List Window and manually take some action to update the model before it can be used. The action that needs to be taken is probably destructive and so we leave it up to the user to decide.

In the next article I’ll explain how “Update Model” makes the decision to create new C-side EntitySets based on new S-side EntitySets and what “identity” has to do with all this.

Lawrence Jones
Software Design Engineer, Entity Framework Tools