Entries:
Comments:
Posts:

Loading User Information from Channel 9

Something went wrong getting user information from Channel 9

Latest Achievement:

Loading User Information from MSDN

Something went wrong getting user information from MSDN

Visual Studio Achievements

Latest Achievement:

Loading Visual Studio Achievements

Something went wrong getting the Visual Studio Achievements

Discussions

Stephen Schaff Vaccano Desktop developers are people too!
  • Am I not getting it or did OData V4 go off the rails?

    , cbae wrote

    *snip*

    If the client application doesn't need these properties, they probably should be private to begin with.

    The client applications does need them.  But I am not allowed to expose them via OData because they are DateTime columns.

    Otherwise, you can make them DateTimeOffset in .NET and map them to datetime in SQL Server. You can manage the data type mapping through the Entity Data Model designer or in code using the fluent API if you're using Code First.

    As I said, the only way to do this (and preserve your naming) is to manually edit the Entity Data Model (CSDL) file.

    If you're using the Entity Data Model designer having to make manual tweaks is already unavoidable if you're mapping table columns to enums.

    Enums?  Who said anything about enums?

    At some point, just deleting all of the entities and re-adding them to reflect the changes to the database is not a viable solution to synchronizing the entity data model with your database.

    Sometimes delete and re-add is the only way to fix problems with Entity Framework data models.  Still, I don't delete everything and re-add.  I just do this to the affected tables/entities.

    Another thing you can do is to create a script that uses the API provided by the System.Data.Entity.Design namespace to automatically change the .NET type of any SQL Server datetime columns to DateTimeOffset in your EDMX file. As far as I can tell, a SQL Server datetime column implicitly converts to .NET DateTimeOffset, and a .NET DateTimeOffset implicitly converts to SQL Server datetime. So there's no need to add any special code like that in the StackOverflow page that you link.

    I tried just changing the type (I hoped there was an implicit conversion too).  But when I tried to run it, I got a type mismatch error.

    Basically, it can't be done without a manual edit to the CSDL or changing your column/property names.

  • Am I not getting it or did OData V4 go off the rails?

    , kettch wrote

    *snip*

    I've done this kind of thing before using partial classes. Since even the generated classes are just POCOs at heart, you can partial up anything you want and it will persist.

    If it were just partial classes I would not complain.  I have done that many times and it works great.

    However, as I said before, this work around requires manual modifications to the CSDL file.  That is unless you are ok with your "OrderedWhen" field being named "OrderedWhen1" or "OrderedWhenDateTime" or some such other name.

    And even so, you have to change the scope of the datetime property to private (so that it does not get exposed to OData).  This means that you have to remember to fix that if you ever regenerate the table (a fairly frequent practice with Entity Framework).

    I suppose I could do all that.  But that is just another layer of complexity in an already complex system.

  • Am I not getting it or did OData V4 go off the rails?

    , cbae wrote

    *snip*

    Are you using EF or any other ORM? If so, you should be able to map DateTimeOffset types in your POCO classes to datetime columns in your database tables.

    When you have a lot of these columns, the time to do it adds up.  But if it was one time work I could "bite the bullet" and get it done.

    But this mapping requires you to edit the entity framework's CSDL.  Since that CSDL gets generated code put into it, my changes can be lost when the designer updates the file or another developer drops and re-adds a table.

    Yes it is a solution, but a dirty one that should not be needed.

  • Am I not getting it or did OData V4 go off the rails?

    , kettch wrote

    *snip*

    Why is it useless? There is only one scenario where you wouldn't use DateTimeOffset: You are writing an application that will never do anything across time zones.

    Before you answer, consider the fact that due to the daylight savings transition, your app will cross time zone boundaries at least twice a year.

    I agree with this if you have the luxury of blue sky development (meaning you get to start from scratch).

    But if you have hundreds of DateTime columns in your system, and a way to deal with the timezone problem already in place, then DateTimeOffset is a lot of work to just get you back to where you already are.

    Which is why I am frustrated that OData decided to drop DateTime.

  • Am I not getting it or did OData V4 go off the rails?

    , blowdart wrote

    *snip*

    So as the owner of a breaking change that is security related in ASP.NET they're not easy to justify. The next version of ASP.NET will turn off the ability to disable viewstate mac. It will break people. I'm not sorry about it. We started talking about it 9 months ago, and issued preview patches. If your app breaks frankly it's for your own good :D

    I don't think that dropping a data type and fixing a security hole can be considered the same kind of breaking change.

    Especially when the OData team could be backwards compatible with DateTime and while offering the new DateTimeOffset at the same time.

  • Newbie to TFS

    +1 for Radio TFS!  It is a great podcast.

  • Am I not getting it or did OData V4 go off the rails?

    , kettch wrote

    @Vaccano: If moving away from DateTime is reason enough to not upgrade to V4, then why would you want to upgrade anyway? Even without the DateTime issue, there has to be new functionality that would justify an upgrade. You'd still be facing changes to the code in order to support that new functionality. 4 > 3 has never really been a good metric when calculating ROI.

    The upgrade from v2 to v3 was backwards compatible.  So it went smooth and we got access to new features like the "Any" and "All" operations.

    In general we try to stay with the current versions so that we don't fall out of support and then have a huge effort to upgrade over 3 or 4 versions.  (We used to not upgrade and it was a maintenance nightmare after a few years.)

    My company has many hundreds of columns that use the DateTime data type.  The  benefits we would would gain by upgrading to v4 are completely blown away by the massive amount of work needed to update (and release) all the applications and WCF services (around 100) that use those columns.

    This all boils down to me being bitter that I am not going to get to use OData v4 because the OData team decided to make all users of the DateTime data type "Legacy Systems".

  • Am I not getting it or did OData V4 go off the rails?

    , blowdart wrote

    *snip*

    Ah, no, I mean our APIs won't give you DateTime. We'll give you something more accurate. It's the more accurate that's "why". If you want to throw that away and downgrade feel free.

    Just like double can be more accurate than integer.  So I HAVE to be more accurate even if I don't want/need to.

    Anyway, this is going to kill an upgrade OData v4 for a lot of systems.  

    I think that the OData protocol makers have over estimated their influence.  Pushing through database changes and application updates take a lot of time.  If I try to put in a change to replace DateTime with DateTimeOffset in perfectly working software so that I can use OData v4, the response to me (and most companies) will be that the ROI is not high enough.

    So, as per your suggestion, we will likely stay on v3 till the OData team comes to (or is brought to) it senses.  Seems a shame to have this version stall out just because the OData team wants to force a data type change on all their users.

    In the end, I still don't get what the OData team gets out of this.  Is supporting both so much more work?  Why are they trying to add the DateTime vs DateTimeOffset fight to their agenda? 

    I assume there are a lot of other datatype issues out there.  Why did the OData team choose to champion DateTimeOffset by killing off DateTime.

  • Am I not getting it or did OData V4 go off the rails?

    , blowdart wrote

    I can't speak for OData obviously, but in ASP.Net v next there's a huge push to move on from DateTime to DateTimeOffset.

    I don't get this.  Why?  Why care if a developer uses DateTime?  Sometimes I just need a DateTime.

    Sure support DateTimeOffset.  Give full tools to use it and all it has to offer.  But leave DateTime in there too.

    Pushing developers out of DateTime and into DateTimeOffset is the same as trying to push developers out of Integers and into Doubles.  In both scenarios you have a data type that offers more precision than the basic data type.  But sometimes you just don't need that extra precision.

    Also, there is a huge amount of existing code out there that will not (or cannot) be upgraded to DateTimeOffset.

  • Am I not getting it or did OData V4 go off the rails?

    , figuerres wrote

    the way .net has done DateTime over web services has been a problem for a long time.

    if you have two systems and an asmx that sends DateTime from one to the other and if they are in different TimeZones then you can have a problem.

    in many cases I sent the date as a string and that was ok. but that will not always work depending on how it will be used.

    I do not know if the odata code had the same problem but what I used to see was the system getting the date time from the web service tried to read it as a "Local time" in the current Timezone but the data was for a date time in a different time zone and so for example my 5pm on the server might be read as 6pm on the client.

    I think MS should do something to any new services but I can also see a lot of code that would break if they try to fix the older code.

    they may have looked at it and felt that this breaking change was "less painful" than some of the other options.

    at least for now they are making the developer look at it and think about  how to work with it.

    I get that there are problems inherent with DateTime.  But as an enterprise, my company has dealt with them outside the data type. 

    In fact, 2 years ago I got to start a new project.  The reason we went with DateTime instead of DateTimeOffset was because at the time, OData did not support DateTimeOffset.  We now have conventions in place that make the timezone information not needed.

    This limitation just causes extra work for me.  And I am going to be exposing a DateTimeOffset where the timezone does not mean anything.

    Again, I just don't see why both were not supported.  Sometimes you just don't need the timezone.