I have not been able to stop thinking about EntityKeys, serialization and web services since my post about them yesterday, so I have done a little more experimentation tonight.

ObjectContext does have an AttachTo method. In my scenario of the incoming object from a web service client, the EntityKey is not available as part of the SalesOrderHeader entity because that is currently not being serialized as part of the entity. Note that this is a bug that the Entity Framework team is aware of and will fix.

While Attach allows you attach an entity that has a key, AttachTo does not require the EntityKey. However it does require that you know the name of the EntitySet.

In the type of testing scenario that I am working with , this is not a big problem.

While Attach would let me call

MyObjectContext.Attach(MyEntitythathasanEntityKey)

AttachTo has me call

MyObjectContext.Attach(MyKeylessEntity,”TheEntitySet”)

Once I do this, the EntityKey is created.

Note the contents of an entity key:

It has the name of the EntitySet in it. (I did not fix up the EntitySet names that the wizard created. I should have done this right after the wizard, and the new designer makes that really easy to do now.) That should be SalesOrderHeaders (plural)).

The EntitySet is nowhere else in the definition of my “incoming” SalesOrderHeader.

So if I didn’t happen to know the name of the EntitySet, I wouldn’t be able to attach it. If I want to have a generic updater, this could be a problem.

And a word or two hundred about concurrency:

The EntityKey itself has no impact on how to handle updates in the service.

As with LINQ to SQL, when I attach an object, it attaches as an unmodified entity. SaveChanges does nothing. The entity keeps track of original and modified values (which you can actually see if you create an ObjectStateEntry object from the entity). I actually tried attaching another instance of the object with different values, then attaching my incoming one to see if the 2nd instance would be seen as modified. No go. (Yah – grabbing at straws…and random ones at that!)

I tried calling Refresh with the ClientWins parameter (along with an array that contained my entity) to see if I could get the database to push it’s original values into the entity and somehow get the incoming values to magically become modified values. There have to be modified values to begin with for any of this to work. That doesn’t change anything because the state of the entity is still unmodified since the time I attached it.

The next thing I tried was updating the ModifiedTime property to see if kicking the ModifiedState of the entity would force all of my changes to get saved. Only ModifiedTime was saved, not the other values that were different.

The last thing I tried was, after attaching the entity, change the value using this funny method:

mySalesOrder.Comment=mySalesOrder.Comment

AND IT WORKED!

The entityState became modified and the Comment column was updated in the database.

So at this point, it still looks like there is no way around explicitly updating the entity properties in order to get them to be seen as modified. But I have no way of knowing WHICH of these things have been changed. Which leaves me a few options (probably more than just these three):

• Update every property
• Cache the entities when they are retrieved from the database (though I have to figure out what I want to cache… a dataset? an entire ObjectContext? … then I have to make decisions about keeping that refreshed).
• Grab the current data from the database just before I want to update. There are also potential concurrency issues with this as well.
• Iterate through each property and, using the ObjectStateEntry, set them as modified using the SetModifiedProperty, which takes the property name (string) as a parameter. I could do this in conjunction with data from the database or data from some cached store and only do this to properties that are different.

However all of these options seem to rely on knowing the name of the properties and I have not been able to find a way to programmatically discover them.

Therefore, it seems that I may have to go down one of these paths:

1. Use reflection to iterate through all of the properties and update them. My feeling about having to go to these lengths is “just no!” Plus this will mean that every property will be seen as modified and will get updated.
2. Write updaters for every entity that will explicitly set each property. That’s a crap load of data access code and not having to write a crap load of data access code is one of the benefits of Entity Framework.
3. Hope and pray that the EntityFramework team can somehow give us a way of attaching an object for original and one for modified. LINQ to SQL has this.
4. Wait for someone on the team to comment in my blog and show me the super easy obvious way that I have totally overlooked.

What’s a little funny to me is that Rick Strahl has had a similar conundrum with LINQ to SQL.

And I’m still only talking about full-on clientWins concurrency, so far.

• #1 Complex Types
• #2 Span [Include]

The next things in the list of what’s new in EF Beta 2 that I have been experimenting with are:

But I still wanted to see about serializing the key, since I was told that I should be able to do that with the independent key. So digging back into the code, I went looking for the EntityKey. I can see it in debug ,

but I couldn’t get at it in code.

This is where I got a look at the IEntitywithKey interface. This interface ONLY exposes the EntityKey.

So now I can get at the EntityKey and can even pull the two together:

However, even if I modified the method so that it returns an EntityKey, there’s a problem problem generating the WSDL and the proxy. Again, not the planned effect, but hopefully a bug.

So I will set this aside for now. (Darn)

There’s still much to look at here including the BinarySerialization.

My biggest interest in serializing entities if for writing multi-tiered applications where entities need to cross machine boundaries and will likely have update conflicts to contend with. I’m personally most interested in Web Services & WCF as this is how I write my smart client applications.

Since we can attach externally created entities to an ObjectContext, this leads to using services to capture entities coming in from a client app and the doing DML operations (update, insert, delete). Attach requires an Entity that implements IEntitywithKey, but AttachTo does not. Nevertheless, when it comes to Updates, the biggest conundrum will be dealing with concurrency and persisting original values somewhere. This is where the EntityKey will be a benefit. We won’t have to go looking for the matching entity, the object service should do that for us.

LINQ to SQL has an override for Attach that allows passing in the original entity and the existing entity, so that it’s own SaveChanges method will be able to determine the modified state of each property. Entity Framework does not have this yet, so finding the most efficient way to handle this is yet to come.

But hey, it’s a holiday weekend and I’ll just have to leave this for another time.= because the sun just came out.

[#1: Complex Types]

The next item in Danny’s list that I wanted to look at was this:

·         Better support for span over LINQ to Entities queries

The span feature makes it possible to pre-fetch related entities.  In previous CTPs span was specified through a property on ObjectQuery<T>, but in this CTP span has been changed to work as a builder method, Include, which makes it simpler to specify span rules in LINQ to Entities queries.  Include can be called on the ObjectQuery used in the from clause of the LINQ query.

This is low-hanging fruit for me because I had seen the use of SPAN in March and tried it out when it was released with the June CTP. Here is the blog post I wrote at that time.

The use of span changed a lot since then. In fact, the word “span” no longer exists!

Previously you had to tell the object context that you wanted to include child data before you actually ran the query. Now you include that instruction in the query itself by attaching the Include property to the object in the query like this query which says to grab the SalesorderHeader info along with the customers.

 Dim custQuery = From cust In aw.Customer.Include(“SalesOrderHeader”)_
 Where cust.SalesPerson = “adventure-works\jae0” Select cust
  For Each c In custQuery
   Debug.Print(c.CompanyName & “…………..”)
   For Each so In c.SalesOrderHeader
    Debug.Print(so.OrderDate)
   Next
  Next

You could also drill in further

   Dim custQuery = From cust In aw.Customer.Include(“SalesOrderHeader.SalesOrderDetail”) _
   Where cust.SalesPerson = “adventure-works\jae0” Select cust
   For Each c In custQuery
    Debug.Print(c.CompanyName & “…………..”)
     For Each so In c.SalesOrderHeader
       Debug.Print(so.OrderDate)
           For  Each sd In so.SalesOrderDetail
              Debug.Print(“…” & sd.OrderQty)
          Next
       Next
    Next

This would get the headers and their child detail records.

You can also define multiple collection properties to grab such as here where I get the salesOrderHeaders and the Addresses for the customer. Looking at how to get at the addresses makes me really happy to have entity framework and the associations doing this job. What a pain in the rear the joins would be otherwise!

  Dim custQuery = From cust In aw.Customer.Include(“SalesOrderHeader”).Include(“CustomerAddress.Address”) _
   Where cust.SalesPerson = “adventure-works\jae0” Select cust
  For Each c In custQuery
   ‘c.SalesOrderHeader.Load()
   Debug.Print(c.CompanyName & “…………..”)
   For Each so In c.SalesOrderHeader
    Debug.Print(so.OrderDate)
   Next
   For Each add In c.CustomerAddress
    Debug.Print(“Cust City: ” & add.Address.City)
   Next
  Next

Outputs:

I looked to see if you could skip a generation eg aw.Customer.Include(“SalesOrderDetail”), but that didn’t pan out. Makes sense, but it only took an extra 5 seconds to be sure.

The nice thing is that include is now explicitly tied to the objectQuery it is used in. No more resetting the object context.

So if you want to do another similar query, you won’t get the related data unless you ask for it. Getting what you ask for is part of the mantra of Entity Framework. No assumptions are made.

Dim custQuery = From cust In aw.Customer.Include(“SalesOrderHeader”) _
   Where cust.SalesPerson = “adventure-works\jae0” Select cust

 Dim custQuery2 = From cust In aw.Customer _
    Where cust.SalesPerson = “adventure-works\shu0” Select cust

The 2nd query will only bring back customer data. If you want SalesOrderHeaders, you will need to explicitly load them as you iterate through the customers.

For Each c In custQuery2
   c.SalesOrderHeader.Load()
   Debug.Print(c.CompanyName & “…………..”)
   For Each so In c.SalesOrderHeader
    Debug.Print(so.OrderDate)
   Next
  Next

I saw complex types in the March CTP of Entity Framework and tried to implement them but found out the hard way that the functionality wasn’t fully implemented. Here’s the forum thread from that time.

So Complex Types were the first thing I wanted to try out on Danny’s list of what’s new in Beta 2. Complex types can only be used as properties of other entities. They have no keys and can only have a one to one relationship with the main entity.

Here is his description:

Complex types “Complex types” is the Entity Framework name for value properties which have more intricate structure than scalars.  The canonical example is an Address type which contains several parts (street, city, state, etc.)  Complex types are somewhat like entities except that they do not have any identity of their own (they are value types).  This means that a complex type instance is always a part of some other enclosing entity—it can’t stand on its own, it doesn’t have relationships, etc.  In this release, the mapping scenarios for complex types are significantly limited: inheritance is not supported, complex type properties cannot be null and they can only occur in single instances, not collections.

I am using the Adventureworks LT database, which can be found on the CodePlex site for SQL Server Product Samples.

I modified the entity for SalesOrderHeader taking the ShipDate and ShipMethod properties and putting them into their own complex type.  I had to do this manually in the XML. There’s no support for it currently in the Designer.

   <ComplexType Name=”ShipmentDetails”>
     <Property Name=”ShipMethod” Type=”String” Nullable=”false” MaxLength=”50″ />
     <Property Name=”ShipDate” Type=”DateTime” />
    </ComplexType>

Then the SalesOrderHeader needs a property to hook up to the ShipmentDetails.

     <Property Name=”Shipment” Type=”Self.ShipmentDetails” Nullable=”false” />

Next I modified the mapping so that it could find the properties in their new spot.

This mean moving the ScalarProperties for those fields into a ComplexProperty. Note that the ComplexProperty is a sibling of the other ScalarProperties inside of the MappingFragment.

The ComplexProperty Name points to the name of the property in the entity and the typename, which has a reference to the namespace of the Conceptual Layer, points to the ComplexType that I created.

The complex type does not get surfaced in the current version of the designer or in the browser. All you can see is the shipment property and it has no Type defined.

But it is well represented in the class that is generated and available in code with help from intellisense:

In the end, I thought something was wrong because all of the ShipDates and ShipMethods were the same, but it turned out that this is what the raw data looks like in the sample database. So I changed some of the data and ran it again to be sure.

Now when I have entities with a lot of properties, I can make them more organized and readable with complex types. Since the designer is only the CTP1, I’m giving them the benefit of the doubt that I’ll see the complex type in the designer eventually.

Note: The complex type came through like a champ when I returned SalesOrderHeaders from a web service.

The first thing I wanted to look at after I downloaded the new Entity Framework Beta2 and Tools CTP was the EDM Designer.

The designer is displayed as the result of opening up an EDMX file. The EDMX file is the wrapper for the three Entity Data Model files (CDSL, MSL, SSDL). Therefore, you need to create a new EDM, either from a database or a blank EDM.

For the sake of familiarity, I created one based on the Northwind database and when asked, I selected all tables, all views and all stored procedures to be part of my model.

When the wizard finished it’s job, I saw this in the output window.

The new EDMX file was displayed in my solution, but I don’t see the xml files any more in the solution explorer. Opening up the EDMX file in an XML tool (rather than the default designer) I see that this contains what used to be the SSDL, the CSDL and the MSL file.

But I’ll worry about that a little later. It was time to double click on the EDMX file and see the designer!

Not only was the conceptual model laid out as expected, but there is an explorer as well where you can drill into the conceptual model and it’s entities and association sets. You can also  drill into the Storage layer.

I noticed these warnings, but if you look closely, they are just saying that the model is not able to create keys for the stored procedures so they’ll be read only. These particular sprocs are just queries for viewing, so that’s fine.

If you select an entity in the designer, you can see it’s mapping to the store model in the output window below.

This is also where you can create mappings. See how you can drop down and select other tables and views from the storage model. The Value/property items are also dropdowns for mapping.

What I didn’t see anywhere is a visual designer for the storage model or for visually mapping between the two.

I know in a screencast from (was it) February (?), the storage layer was not only part of the designer, but malleable. Perhaps we’ll see that in a future CTP.

Clicking around in the designer, you’ll find a context menu also. Here’s a function for exporting the diagram.

And playing around in the explorer you can see tooltips of the xml that represents the various bits and pieces of the schemas.

One thing I have been struggling with since the June CTP came out was stored procedures. There is finally an example that appeared in the forums today and also in the help file that came with the Beta2.

Since the designer is now the default for opening up the edmx, I need to right click on it in Solution Explorer and open with the XML Editor instead. It will be interesting to watch the cause and effect as I work from both ends now.

FINALLY!!!!

I’m just downloading them now.

Read more about it and get the links at the ADO.NET Team blog, here.

I was looking at a LINQ Query that I wrote when I was first exploring LINQ in depth at the beginning of the year.

This example was to see how to create a named anonymous type like this:

Dim query= From s In nw.Suppliers _
    Order By s.CompanyName _
    Select Supp = New With {s.CompanyName, s.Country, s.Products}

Looking at it today though I could not see what creating a name (Supp) for the new anonymous type was buying me in this particular case.

Its results were no different than

Dim query = From s In nw.Suppliers _
 Order By s.CompanyName _
 Select s.CompanyName, s.Country, s.Products

And whether I iterate through the results or bind them to a data control, there’s no still no difference.

So I wanted to make sure i was clear on when naming the anonymous type was beneficial.

One great example is in the (dog-eared by now) LINQ article that Anders Hejlsberg and Don Box wrote in February where the LINQ query results in objects with child objects. I’ve used the idea behind their couple/wife/husband example to create my own query where I combine data into new types.

For example, this query lets me create a type from some product data with a new sub-type (anonymous) of SupplierHighlights. The sub-type has only the properties Name and Country.

Dim MyQuery = From p In db.Products _
Select p.ProductName, p.QuantityPerUnit, _
SupplierHighlights = New With {.Name = p.Supplier.CompanyName, .Country = p.Supplier.Country}

Then I can access the new type and sub-type data because the subtype has a name.

For Each q In MyQuery
     Console.WriteLine(“Prod Name: {0},Quantity Per Unit: {1}, Supplier: {2}, Country: {3}”, q.ProductName, q.QuantityPerUnit, q.SupplierHighlights.Name, q.SupplierHighlights.Country)
    Next

Sure, I could have just created properties called SupplierName and SupplierCountry, but having the child type SupplierHighlights not only makes me more organized, but gives me the ability to do further queries if I wanted to get all of the supplier info out of the product query. This is why I am considering SupplierHighlights to be a type rather than just a property within a complex type and I should point out that I could be incorrect in calling it a type, but will stick to it until I find better evidence that it’s not. Because I have everything already grouped into a supplier type, I don’t have to list each of the fields (SupplierName, SupplierCountry), I can just query :

   Dim nextQuery = From prod In query Select prod.SupplierHighlights
    For Each s In nextQuery
     Debug.WriteLine(s.Name, s.Country)
    Next

So, here creating the named type (I really want to call it a named anonymous type. I wonder if that’s accurate?), it is really useful and necessary. Try creating the sub type without a name, and you’ll see what I mean!

Another place to leverage the named type SupplierHighlights is in databinding. I can databind directly to prod.SupplierHighlights and automatically get all of the columns. In databinding to the properties of the base query results (ProductName, QuantityPerUnit), I have to bind to “MyQuery”, so even if I had named that type, I don’t use that name anyway.

Also,  take a look at this post by Paul Vick about mutable and immutable anonmyous types in VB9.

(The italicized text are a result of feedback from Bill McCarthy, who is constantly (and generously) attempting to drag me down into the depths of complexity of VB.)

I just came across this interview on the INFO-Q website. I like how they do this. Short questions and answers. Each q/a has a video clip, where you can watch and listen to the subject of the interview and simultaneously read the text of the question and answer. That makes it really easy for me to paste these two tidbits.

Basiically he says LINQ to SQL is for simple database scenarios and EDM (Entity Data Model) is for very complex schemas and giant databases. Not earthshatteringly different than what are figuring out, but interesting to hear it from the guy who is credited for inventing LINQ. He’s NOT comparing it to Entity Framework, since there’s more to Entity Framework than the EDM that lies at it’s core. Here is a post about Mike Pizzo comparing LINQ to SQL and Entity Framework directly.

What about DLINQ (aka LINQ to SQL)? 
DLINQ is and instance of LINQ over Relational Data, which is trying to address the simpler mapping scenarios. In DLINQ there are several ways to do this. You can point at your database and get your classes from the metadata and the database, you can put custom attributes on your classes, and define your mapping like that or you can use an external mapping file. DLINQ, like many other object relation mappings, has this notion of context, which is the bridge between the object world and the database world, that does the change tracking and holds the database context, and the transaction context and so on. Also this context will take your expression trees, translate them to SQL and then materialize your objects. DLINQ is one example of using LINQ to query against Relational Data.