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
Vous devez vous connecter pour publier un commentaire.
Jusqu'à présent, DateTime n'est pas la partie de la OASIS OData V4 standard et API Web ne prend pas en charge le type DateTime alors qu'il ne l'appui de la DateTimeOffset type.
Cependant, OData Équipe de travail sur le soutien de la DataTime type maintenant. J'imagine que vous pouvez utiliser le type DateTime dans la prochaine API Web de libération. Si vous ne pouvez pas attendre pour la prochaine version, j'ai écrit un exemple basé sur le
blog . L'espoir peut vous aider. Merci.
Modèle
DB Contexte
EdmModel
Contrôleur
Ajouter le OData Contrôleur comme d'habitude.
Test
Charge utile
Enfin API Web OData v4 prend désormais en charge
DateTime
type dans la version 5.5 . Obtenir la dernière version de package nuget et n'oubliez pas la définition de cette:sinon le fuseau horaire de la date de la propriété serait considéré comme un fuseau horaire local.
Plus d'infos:
ASP.NET l'API Web pour OData V4 Docs DateTime support
DateTime
type signifie que vous pouvez filtrer les DateTimes comme je l'ai fait dans mon projet. Comme vous l'avez mentionné, il convertir le DateTime pour DateTimeOffset elle nous permet de filtrer un DateTime.Une autre solution est de patcher le projet, de sorte que
DateTime
est autorisé à nouveau - c'est ce que j'ai fait, vous pouvez obtenir le code ici si vous le souhaitez:https://aspnetwebstack.codeplex.com/SourceControl/network/forks/johncrim/datetimefixes
J'ai également fait un package NuGet pour le rendre facile à utiliser, vous pouvez obtenir le package à l'aide de l'info ici:
http://www.nuget.org/packages/Patches.System.Web.OData/5.3.0-datetimefixes
... Je ne sais pas si c'est ok pour moi de poster un package NuGet contenant une version patchée de Microsoft bibliothèque, j'espère que c'est plus facile de demander pardon que la permission.
Noter que l'élément de travail officiellement à restaurer la capacité d'utiliser DateTime dans OData 4 est suivi ici:
https://aspnetwebstack.codeplex.com/workitem/2072
Merci de voter pour la question si vous souhaitez le voir; mais il semble que c'est prévu pour 5.4-bêta, donc il devrait être à venir un de ces jours.
ValueFactory
àGlobalConfiguration.Configure(WebApiConfig.Register);
ValueFactory attempted to access the Value property of this instance
dès que j'essaie d'utiliser le 5.3.0 pré pourMicrosoft.AspNet.Odata
qui est pré-requesite pour le patch.config.MapHttpAttributeRoutes();
ce n'est pas de travailler avec le5.3.0
version. Mais, maintenant, je suis en cours d'exécution le OData 4.0 avecDateTime
, mais quand j'essaie de poster un json comme ceci:{ name: 'iPhone 6', releaseDate: '2014-08-08' }
ne fonctionne plus. J'ai remplacé le DateTimeOffSet de type DateTime dans ce ReleaseDate champ (il fonctionne avec DateTimeOffSet). Donc la j'obtiens une valeur null pour le Delta<Produit> dans mon post/put/fusion/patch méthodes.Cette solution de contournement et de celui de
http://damienbod.wordpress.com/2014/06/16/web-api-and-odata-v4-crud-and-actions-part-3/, ni travail. Ils travaillent d'une façon seulement, ce qui signifie que quering odata datetimeoffset avec le filtre de commande échoue parce qu'il ne fait pas partie du modèle.
Vous ne pouvez plus filtrer ou trier par ces champs ou d'obtenir cette erreur
Donne cette erreur:
Mais cela fonctionne comme il est adressé indirectement:
Rappel et Iscomplete date et le datetiem de l'activité par le biais de AppUserActivities.
C'est bizarre que ça fonctionne. Quelqu'un aurait-il une solution?
- Je me connecter à MySQL. Il n'y a pas un datetimeoffset.
Et tout le monde se demande pourquoi personne ne veut de développer des technologies de Microsoft.
Malheureusement, https://aspnetwebstack.codeplex.com/SourceControl/network/forks/johncrim/datetimefixes fourche, donnée par crimbo n'a pas vraiment de soutien DateTime.
Il y a la nouvelle fourche https://aspnetwebstack.codeplex.com/SourceControl/network/forks/kj/odata53datetime?branch=odata-v5.3-rtm basé sur OData v5.3 RTM, où DateTime propriétés dans les entités et les types complexes sont pris en charge dans le serveur de réponses, client POST/PUT/demandes de correctifs, $orderby et $filtres clauses, les paramètres de la fonction et retourne. Nous commençons à l'utiliser dans le code de production et de soutien à cette fourchette, jusqu'à ce que DateTime soutien sera de retour dans les futures versions officielles.
Depuis que j'ai utiliser une bibliothèque pour odata angulaire, j'ai étudié il y:
Là, vous pouvez voir ( javascript)
Et le test attend ( cfr. ici )
Ce qui devrait être votre "mise en forme"
Ressemble à une cartographie DateTimeOffset <-> DateTime sera inclus dans Microsoft ASP.NET l'API Web 2.2 pour OData v4.0 5.4.0:
https://github.com/OData/WebApi/commit/2717aec772fa2f69a2011e841ffdd385823ae822
Installer Le Système.Web.OData 5.3.0-datetimefixes de https://www.nuget.org/packages/Patches.System.Web.OData/
Avoir passé une journée frustrante qui tente de faire la même chose, j'ai juste trébuché à travers la seule façon que je pouvais le faire fonctionner. Nous voulions être en mesure de filtrer par date de plages à l'aide de OData et API Web 2.2, ce qui n'est pas rare de cas d'utilisation. Nos données dans SQL Server et est stocké en DateTime et nous sommes à l'aide de EF dans l'API.
Versions:
Entité Extrait De:
WebApiConfig
Contrôleur Extrait De:
Ici est la magie de bits de voir le fond de cette page MSDN dans la rubrique "Référencement des Différents Types de Données dans les Expressions de Filtre" et vous trouverez une note disant:
Jusqu'ici, nous avons ce travail de Postier et nous sommes en train de construire le client qui devrait, espérons-le travail avec cette exigence de bâton 'datetime' en face de la valeur réelle. Je suis à la recherche à l'aide de Simples.OData.Client un contrôleur MVC, mais on peut même décider de faire appel directement à l'API à partir du code JavaScript coté client en fonction de combien de refactoring nous avons à faire. Je tiens également à obtenir Swagger INTERFACE de travail à l'aide de Swashbuckle.OData, mais c'est aussi la preuve d'être délicat. Une fois que j'ai fait tout ce que j'ai le temps, je vais poster une mise à jour avec les infos utiles pour ceux qui suivent comme je l'ai trouvé très frustrant que c'était si dur de trouver la façon de faire quelque chose qui est en apparence une simple exigence.
À la fois les travaux suivants avec ODATA 4
c'est la Dernière mise à jour que je vois avec .Net de 4,7 et Microsoft.Aspnet.ODATA 5.3.1
$filtre=DateofTravel lt cast(2018-05-15T00:00:00.00 Z,Edm.DateTimeOffset)
cela fonctionne aussi , il doit être dans ce aaaa-mm-jjthh:mm:ss.ssZ
$filtre=DateofTravel lt 2018-02-02T00:00:00.00 Z