Yes, my cat just ate your socks

Data Type Not Supported By The Designer?

destructothedevilcat — Fri, 20 Mar 2009 22:26:45 +0000

If, like me, you were really excited by the new SQL Server 2008 data types. However, after trying to use the more interesting of the types (geography, geometry, and hierarchyID) with LINQ to SQL or the Entity Framework, you received an error that says, “One or more selected items contain a data type that is not supported by the designer”. What the heck is going on here? Well, that is just Microsoft’s cryptic way of saying the code generator can’t serialize at least one of the fields in one of the tables. To be more specific, neither LINQ to SQL nor the Entity Frame work can serialize UDTs (user defined types), which is exactly how the new geography, geometry, and hierarchyID types are implemented. Last week I went to an MSDN Road Show and asked one of the .Net evangelists if/when this would be resolved. He responded, “I have an answer, but you’re not going to like it”. He went on to say that although several teams wanted to work on the problem, there were no plans to fix the problem by time VS10 was released. This, is hugely unfortunate as it is a gaping hole in an otherwise intriguing set of functionality. I’m not quite sure why it’s not in the works; serialization is a problem that has been solved many times over. I wholeheartedly encourage everyone to pester anyone they can at Microsoft to get this done by the VS10 release.

Fortunately, he did say that the issue both ORM’s were having with the precision of the new Time data type was on the list of things to address; perhaps even as a service pack.

Now that I’ve vented a bit, there are several ways to use the new types with LINQ to SQL and the Entity Framework (although they are less than elligant). In my next post I’m going to go over the spatial data types in a bit more detail. Then I’ll cover one of the methods of incorporating a table with a geography column into your LINQ to SQL data context.

SQL Server 2008, LINQ to SQL, and the Entity Framework (Part 1)

destructothedevilcat — Fri, 06 Mar 2009 23:57:24 +0000

As most of you probably already know, SQL Server 2008 introduced several new data types that cover four basic categories: chronological, spatial, hierarchical, and data storage. Most of the data types are straight forward and have been covered by others (e.g. Brad McGehee). Most of these data types can prove extremely useful, however using them in conjunction with LINQ to SQL or the Entity Framework presents a series of obstacles (some much larger than others). In this post I will be covering a fun little problem involving the new Time data type. My next several posts will be about the spatial data types (at least two and possibly three posts depending on feedback).

For this post we will be using an example where we have events that recur several times during a week. For our demonstration purposes a single table from the database will suffice:

Now that we have our schema, lets import the table into our LINQ to SQL DataContext.

Now we will write a little test to make sure everything is working as we expect.

As you can see this is a pretty straight forward test, we’re just creating a new record, editing, then deleting it. However, when we run the code we get the following error:

At this point, you may be scratching your head as I was when I first encountered the problem. So after running the test about twenty more times hoping the problem would magically go away, I decided to do some digging. Naturally, I started by debugging the test and sure enough, the RecurringEventID is the same as that of the record in the data base. Going one step further, I decided to look at the query that LINQ to SQL is using:

At this point I smacked my forehead and said “OH! That sucks…”. If you don’t see what the problem is yet, don’t feel bad, apparently the ADO.Net team still doesn’t realize it. In order to show you what’s wrong, let’s take a look at the auto-generated code for the TimeOfDay property.

At this point, you’ve probably figured out what the problem is. If not, I’ll give you a hint; take a look at the Column attribute. You’ll notice that there is no information about the precision of the Time field. Consequently, when the update query statement is created, the framework has no way to know it should be rounding the Time to the nearest second. This is a HUGE problem! Ok, well it’s not huge, but it IS a huge pain. The quick and easy work around is to make sure you use Time(7) so rounding wont be an issue.

For those of you asking about how the EntityFramework handles the new Time data type, it handles things a bit more gracefully but it wouldn’t be as easy to catch. When you try to update the object, the SaveChanges method returns 0 which makes sense. What doesn’t make sense is that it actually deletes the record successfully. So much for concurancy right?

Unfortunately, this is by far not the only issue both LINQ to SQL and the Entity Framework have with the new SQL Server data types. In the next few posts I will be going over the spatial data types in a bit of detail and how to integrate them into your LINQ to SQL DataContext. The more feedback I get the more in depth I will go. I just don’t want to through all the trouble of writing the posts if no one cares.

Composable and Efficient LINQ Queries

destructothedevilcat — Sun, 15 Feb 2009 15:51:54 +0000

Whether you come from a functional, procedural, or object oriented background, it’s always a good idea to promote code reuse as much as possible. One of the best ways to have reusable LINQ queries is to write them in a composable fashion.

Put simply, composable methods are those that you can chain together to build the desired functionality out of smaller parts. Take the following for example:

Although its a bit contrived, if you wanted a slightly different result set, you would have to recreate most of the query logic. If, however, you used composable methods like the following you only have to create the new logic that’s required instead of reinventing the wheel:

Creating composable methods is actually quite easy, essentially all you need to do is make sure the return type of a method is the same as the input type. For instance, the following could be the signature for the FilterByType method:

As any good little programmer should do, most of us use the most basic type possible for our method signatures. The problem is, that could be the exact opposite of what should be done. Although IQueryable inheirets from IEnumerable, it is often the case that using IQueryable is more appropriate.

Why is this an issue? Well, the LINQ queries are evaluated differently on IQueryables than on IEnumerables. More specifically, queries on IEnumerable collections are evaluated immediately while those on IQuerable collections aren’t evaluated until you enumerate over the results (which includes converting the collection to an array, list, or any other type of IEnumerable).

To see what is actually going on, we will go through some examples and log the SQL that is actually passed to SQL Server, for which we will use the DataContext.Log property. If we were to run the SQL-like LINQ query above you would find the SQL to be something like the following:

This is what you would expect to see; however, if you were to use the extension method we defined above, FilterByType, you may be surprised to see:

So what happened? Well, since the extension method we wrote was defined for an IEnumerable, the .Net framework chose the IEnumerable version of LINQ’s Where extension method. Consequently, all records from the Vehicle table will be returned and loaded as LINQ objects into an IEnumerable collection. At this point each object would be enumerated over to see if they meet the qualifications of the predicate we passed to the Where method. As you might expect, this is far from performant and could become a large bottleneck within your application.

So, now what? Well the obvious answer would be to simply change the extension method to be for IQueryable instead of IEnumerable. The problem with this is now you have an API that is less than friendly to use if you have a non-IQueryable collection, for instance a List. Instead, I would propose that you have an extension method defined for both the IQueryable and IEnumerable collections, after all this is what the .Net framework does. Your comment now would naturally be, “Wait, I thought we were trying to avoid duplicate code”. Well, you’re right; we are trying to avoid duplicate code, which is why we will be employing the AsQueryable extension method within the IEnumerable version of the extension method.

The runtime cost of using AsQueryable is virtually nothing and now you can use your logic for both IEnumerable and IQueryable collections. You now also have the opportunity to optimize the queries for a particular type of collection if possible.