Comment obtenir de l'API Web OData v4 utiliser DateTime

J'ai un assez grand modèle de données que je veux exposer à l'aide de l'API Web OData à l'aide de la OData protocole V4.

Les données sous-jacentes sont stockées dans une base de données SQL Server 2012. Cette base de données a beaucoup de colonnes DateTime en elle.

Comme je l'ai été il câblage jusqu'j'ai eu une erreur du Système.DateTime n'est pas pris en charge.

Voici donc ma question, que puis-je faire pour obtenir mon colonnes DateTime pour être vu dans le flux OData?

NOTE: je ne suis pas en mesure de revenir en arrière et changer tous mes colonnes à DateTimeOffset colonnes.

J'ai essayé de changer le type de la colonne, dans le Cadre de l'Entité edmx, mais il m'a donné ce message d'erreur:

Membre de la Cartographie spécifié n'est pas valide. Le type 'Edm.DateTimeOffset[Nullable=False,DefaultValue=,Précision=]' membre 'MyPropertyHere' en type 'MyProject.MyEntity "n'est pas compatible avec" SqlServer.datetime[Nullable=False,DefaultValue=,Précision=3]' membre 'MyColumnName' en type 'MyDataModel.Magasin.MyEntity'.

(Bascially syas que DateTime n'est pas compatible avec DateTimeOffset.)

Ne l'API Web OData équipe vraiment il suffit de laisser tout le monde qui a besoin d'utiliser le Serveur SQL de type de DateTime?

Mise à jour: j'ai trouvé des solutions de contournement pour cela, mais ils nécessitent une mise à jour du Modèle EF pour eux de travailler. Je préfère ne pas avoir à mettre à jour plusieurs centaines de propriétés individuellement si je peux l'éviter.

Mise à jour: Cette question m'a fait réaliser qu'il y a de graves défauts dans la façon dont Microsoft est la gestion de son OData produits. Il y a beaucoup de questions, mais c'est le plus flagrant. Il y a d'énormes fonctionnalités manquantes dans les API Web OData. Les Transactions et la commande de plaquettes deux d'entre eux. Ces deux éléments (qui sont dans les spécifications de OData et ont été dans les Services de Données WCF avant que Microsoft l'a tué) sont essentiels à tout système réel.

Mais plutôt que de passer du temps dans ces endroits critiques où ils sont absents de la fonctionnalité qui est dans la Spécification OData, ils décident de passer leur temps sur la suppression de la fonctionnalité qui a été très utile pour de nombreux développeurs.
Il incarne la mauvaise gestion de la priorité à la suppression de caractéristiques de travail sur l'ajout de mal fonctionnalités nécessaires.

J'ai essayé d'en discuter avec l'API Web OData représentant, et à la fin, j'ai eu un problème/billet ouvert qui a ensuite été fermé quelques jours plus tard. C'était la fin de ce qu'ils étaient prêts à le faire.

Comme je l'ai dit, il ya beaucoup plus de problèmes (et non pas liées à DateTime, je ne vais pas les énumérer ici) avec la gestion de l'API Web OData. J'ai été un fervent partisan de l'OData, mais la flagrante des problèmes avec l'API Web OData de gestion ont forcé de moi et de mon équipe ou de l'entreprise à l'abandonner.

Heureusement, normal API Web peut être configuré pour utiliser OData syntaxe. C'est plus de travail pour l'installation de vos contrôleurs, mais il fonctionne très bien en fin de compte. Et il prend en charge le type DateTime. (Et semble avoir une gestion qui peut au moins rester à l'écart de rendre incroyablement mauvaises décisions.)

  • Actuellement, l'api web odata ne prend pas en charge DateTime, il y aura peut-être une solution. Il y a une question similaire, avec un travail autour de, espérons que cela aidera à stackoverflow.com/questions/24829422/...>
  • En réalité, les gens ont demande pour l'interdiction des DateTime (demande ici). Êtes-vous sûr que votre client fuseau horaire est le même que votre serveur? L'utilisation de tout type de données de temps, sans spécifier le fuseau horaire est juste des ennuis. C'est une autre catégorie de problèmes de localisation, semblable à supposer un certain code de la page, le format de date ou de caractère décimal. C'est le modèle qui doit être réparé, pas le protocole OData
  • Je suis tout à fait sûr.
  • Alors s'attendre à une douloureuse prise de conscience dans l'avenir. EST, PST ou GMT? D'été ou d'hiver? Ce qui se passe lorsque le commutateur à partir de l'été à l'heure d'hiver se produit? Allez-vous enregistrer les dates de commande? Juste parce qu'il n'est pas encore arrivé ne signifie pas qu'il ne sera pas. Pour ne pas mentionner temps qui exigent le fuseau horaire info par exemple. vol de départs et d'arrivées, événement local etc. Il est préférable d'être explicite à ce sujet plutôt que d'utiliser des hypothèses qui sont voués à l'échec
  • Nous sommes contraints par d'autres (les plus grandes applications) à l'utilisation de notre fuseau horaire. L'heure d'été est facilement traitée avec une heure de temps d'arrêt. Des scénarios du monde réel, sont rarement aussi coupé et séché comme spec concepteurs voudraient bien le croire. Si j'avais le luxe de faire une nouvelle demande actuellement, je utiliser DateTimeOffset? Bien sûr. Mais nous gérons le datetime questions maintenant très bien. N'oubliez pas, les fuseaux horaires qui ont existé depuis des Décennies, mais DateTimeOffset n'a été pris en charge dans OData pour quelques années seulement. Il est naïf de croire que il n'y a pas d'autre moyen de traiter avec elle.
  • tout à fait !! (Je suis totalement d'accord) mon client apps ont tous été soigneusement conçus et construits de manière à ne présumons de RIEN à propos de ce que la date / l'heure qu'il est - ils prendre cette info à partir du serveur, et jusqu'à une demi-heure (quand j'ai mis à jour à partir de odata 3 à 4) ma journée allait bien. CE QU'UN TOTAL DE DOULEUR.
  • Juste voté aspnetwebstack.codeplex.com/workitem/2072
  • Comment agit toujours de l'envoi de l'UTC datetime et de laisser le client de prendre soin de conversions pour toute l'INTERFACE utilisateur?
  • Qui ne fonctionne pas - ce décalage parlons-nous? Javascript du format (et Json est aujourd'hui) est la norme ISO 8601 qui ne comprennent TZ décalage. Il n'y a pas de problème avec ODATA ou la spécification de format. Le problème est que ASP.NET Web de l'API de mise en œuvre n'est pas automatiquement supposer/en déduire un fuseau horaire lorsqu'il est présenté avec une valeur de type DateTime. Ces valeurs peuvent être soit UTC, local ou indéterminée, comme illustré par la DateTime.Genre de la propriété. Je pense que c'est le Unspecified valeur qui est à l'origine des problèmes

InformationsquelleAutor Vaccano | 2014-08-07