The importance of profiling your application

It is well known that the ORM can help a lot in software development. In fact, they solve many problems that as developers we had in the past, specially talking about Opening and Closing Connections.
But as ORM frameworks are a powerful tool,they can also make a mess if they are not used in the proper way. Let me give you an example.
In the project I'm current working on, some users started experiencing some slowness when trying to load a page. I was assigned to investigate what was happening and propose a solution. I started by doing some profiling in the web application using Glimpse, adding some Trace messages to determine where was the problem and I noticed that the it was in a WCF service call that was taking 20 seconds to retrieve a single record with a lot of columns (because of all the needed joins).
This was by far unacceptable, so I started to doing further profiling on the Entity Framework using Entity Framework Profiler, and discovered that the slow service data was being fulfilled by a 4,000 lines query!.
I clearly understand that EF made a lot of extra and maybe unnecessary joins in order to automate the data exctraction, but, 4000 lines?! Really?!
After inspecting the long long query that EF Profiler showed me, I started noticing some duplicated SELECT statements. Then I went back to the service call and noticed that the code was something like this:

...
AsQueryable()
.Include("Account")
.Include("Account.Client")
.Include("Account.Client.Organization")
...

This seemed to be good on the first look, since we wanted to get the Account, the Client of that Account, and the Organization. But what EF is understanding is that we want to get the Account, and then AGAIN the Account and the Client, and then AGAIN the Account, AGAIN the Client and the Organization. This then was causing that duplicated SELECT statements I was talking before. So to fix the problem I deleted the extra lines and the code ended up like this

...
AsQueryable()
.Include("Account.Client.Organization")
...

and then by that, I reduced the lines of the resulting query, removed all the duplicated SELECT and reduced the execution time to 2 seconds!
So, as you can see, two extra lines can screw all the work you're doing. So be careful of preventing this and do profile your applications before they go live. CodeProject

Read More

Solution to: "The operation failed: The relationship could not be changed because one or more of the foreign-key properties is non-nullable"

The operation failed: The relationship could not be changed because one or more of the foreign-key properties is non-nullable. When a change is made to a relationship, the related foreign-key property is set to a null value. If the foreign-key does not support null values, a new relationship must be defined, the foreign-key property must be assigned another non-null value, or the unrelated object must be deleted.

Problem description

The error quoted above happened to me after I started using AutoMapper on my WCF service for updating my entities. Previously, I had a "manual map" to assing the properties that I received on my data contract to the entity that I got on my context and update it. When we decided to implement AutoMapper on our project, my mapping code started like this:

Mapper.CreateMap<MyDataContract, MyEntity>.IgnoreAllNonExisting();

Since all my properties were named the same on both classes, everything seemed to be easy peasy.

But sadly, I started gotting the error message

The operation failed: The relationship could not be changed because one or more of the foreign-key properties is non-nullable. When a change is made to a relationship, the related foreign-key property is set to a null value. If the foreign-key does not support null values, a new relationship must be defined, the foreign-key property must be assigned another non-null value, or the unrelated object must be deleted.

This message was driving me crazy, because of the text I was thinking that I was making something wrong with the FK relationships on the Database, or in someway the field was being passed null without being null on the contract, or somebody changed the table in someway (yeah sure, blame others :-P). After some deep look on the code (including debugging line by line all the updating process) I found the error.

Since I'm copying the modified values (from DataContract to Entity) when mapping, I'm passing all the values from one instance to the other. This sounds OK, right? I mean, I want all my changes to be persisted on the database.

Well, is not that easy. Since my contract comes from a web application, when saving there I don't have all the navigation properties. When this is the case and I just map all, I'm also mapping and overwriting the values of this navigation properties, that in this case are null on my DataContract. This makes the Entity to update the ForeignKey Columns that belong to that navigation property to be null too. That is why the error says that you're sending null values, because actually you are.

Solution

Since the problem is that we're mapping null navigation properties, and we actually don't need them to be updated on the Entity since they didn't changed on the Contract, we need to ignore them on the mapping definition:

ForMember(dest => dest.RefundType, opt => opt.Ignore())

So my code ended up like this

Mapper.CreateMap<MyDataContract, MyEntity>
ForMember(dest => dest.NavigationProperty1, opt => opt.Ignore())
ForMember(dest => dest.NavigationProperty2, opt => opt.Ignore())
.IgnoreAllNonExisting();

And voilà! the problem is solved. CodeProject

Read More