I understand that dealing with nullable types is a function best handled by the individual providers (especially considering the difference in semantics between backends), and I'm sure support will come with time. However, I'm especially disappointed that the Convert class, normally the "hero to the rescue" around DBNull, was also not updated. There's no ConvertToNullableInt32(...) or anything of the sort- we're left with rolling our own conversion methods or inlining things like:
int? MyNullableInt = reader["anInt"] is DBNull ? null : reader["anInt"];
Ick. I feel like I need a shower right now just having typed it. I'm hoping LINQ to SQL will support nullables in a more friendly manner (I seem to recall that it does, but I won't find out for sure until Orcas hits beta- don't have the bandwidth to mess with it now).
I found this recently, which looks similar to what I was considering writing... Still need to peek inside to see if I feel comfortable using it, but there's not really much to it. This covers half of what's missing. The other half is in the parameter type inference model used by individual providers. For instance, the following code breaks:
int? someIntValue = 5;
SqlCeParameter parm = new SqlCeParameter("@MYINT", someIntValue);
since the SqlCeParameter class has a hardcoded list of conversions to its internal datatypes, and Nullable<int> isn't in it. Again, this behavior is understandable- SQL CE has to work on 1.x CLRs, but that doesn't make me feel much better when I live in 2.0.
Oh well. I'm off the soapbox for tonight.
Post a Comment