Archive | July, 2014

WebApi 2.2 OData v4.0: When inexperience and academics impede real-world progress. What a shame!

23 Jul

So you’re excited about the release of WebAPI for the OData v4.0 protocol? You can’t wait to use the new features that will now allow you to code more efficiently and throw out your hacks from v3? We were glad to finally get rid of the $format “hack” along with tons of routing code that v4 can now handle more efficiently for us. Not to mention the relative ease of working with the oDataController in WA22OD4.

Alright, now we are ready to analyze our options as we prepare to move forward with a massive platform API to serve our SaaS clientele with mobile and developer OData access, widgets, remoting services and much more. And from what we can gather, WA22OD4 sure seems to offer us a rapid pathway to our end game. We were about ready to rumble, but in the spirit of always trying to go with the latest and greatest, I decided that we should try OData v4 before launching the API platform.

Went through the checklist:

  1. Updated from WebStack? 
  2. Fixed breaking changes
  3. Commented out old hack code? 
  4. Changed Controllers to oDataController and modified for correct functionality? 
  5. Feeling relieved by how smooth things are going? 
  6. Sit back, press the proverbial TEST button (Fiddler) and watch how life has just gotten better?   Uh…Oh!

The type ‘System.DateTime’ of property ‘Date’ in the ‘CompanyAPI.Models.AuthorizationResponse’ type is not a supported type. Change to use ‘System.DateTimeOffset’

What the heck is this?  Since when is DateTime not supported in ANYTHING?

At that moment, a scary thought runs through my head. Did the datatype standards change for datetime years ago and I’m the last person on the planet to find out? Of course, it has been known for some time that DateTimeOffset was to become the norm, but to just stop supporting DateTime so abruptly? This is a scary thought because with over 600 tables in our various databases and millions of lines of code that make up our platform (some legacy), I can’t even begin to imagine what it will take to start down such a conversion path. After all, we are about to launch our API. Nope, maybe in the near future, but for now we don’t have time for such an endeavor.

So I began my investigation into what must obviously had been a misunderstanding on my part. Then, to my utter amazement, I ran across this work item on codeplex. With the shocking title of OData V4 service should not support DateTime.

Wha.. Wha.. WHAT?

In reading further I notice that some clients in various scenarios were having issues with DateTime typed values and metadata. That’s a bummer. I guess if I run into those issues, then I’ll have to work for my money and find a way around it.

Now, you would think that the team would come up with workarounds or even announce deprecation of DateTime in models for future OData releases.

Well, you would be wrong. One simple, non-chalant sentence in the youthful team member’s work item post said it all:

‘We should generate a proper error message when DateTime is used in the model.’

Wait! Did he really just say that? Is that from this team or committee’s “decades” of experience?<si> Or maybe their academic adherence to all things, well, academic? Granted, a warning or even a deprecation into eventual obsolescence, maybe. Or even introduce methods for conversion on the wire. But to flat out throw an exception with DateTime in such widespread use around the globe? Preposterous! It was being buggy so just throw out support for one of the most commonly used datatypes?

And NO, I don’t want to go hacking around in the POCOsphere or change the generated entity classes as I use the Update model feature frequently and don’t want to deal with versioning my changes every time. I also don’t want to add a myriad of code that will hang around and potentially be overlooked when a more suitable solution presents itself.

So what is it with the DateTimeOffset?

I won’t get into specifics and bore you, but there is a preference to use the DateTimeOffset so that the value will be a specific set point in time, not a relative time like with DateTime (especially of DateTimeKind.Unspecified). Ok, that makes sense. But our platform operates in a manner which DateTime does the job. Maybe sometime in the near future we will look at changing to DateTimeOffset as it would be more beneficial for a variety of reasons. But for now, DateTime is in widespread use throughout, as is the case with the majority of .NET platforms worldwide.

With that said,

I know that most, if not all of those involved in this decision, both with MS and OASIS, are bright individuals that are just driving 100 miles a minute to get something where they envision it to be or feel strongly in their pursuit of strict adherence to standards. As an innovator and fellow problem solver, I can appreciate their desire to not let little things get in the way of the big picture. But with age and experience comes the wisdom and understanding that some of those little things can cause huge ramifications if not handled with proper care, consideration and planning.

What can you and I do about it?

Make them see the error of their ways!

Vote up!

Work Item: OData V4 service should support DateTime

You can view the OASIS committee proposal here: https://issues.oasis-open.org/browse/ODATA-220