Modifications ayant un impact sur le fournisseur

  • Article

Cette page contient des liens vers des demandes de tirage (pull requests) effectuées sur le référentiel EF Core qui peuvent nécessiter que les auteurs d’autres fournisseurs de base de données réagissent. Notre intention est de fournir un point de départ pour les auteurs des fournisseurs de base de données tiers existants lors de la mise à jour de leur fournisseur vers une nouvelle version.

Nous commençons ce journal avec les modifications de 2.1 à 2.2. Avant la version 2.1, nous utilisions les étiquettes providers-beware et providers-fyi sur nos problèmes et nos demandes de tirage (pull requests).

2.2 ---> 3.x

Notez que la plupart des changements cassants au niveau de l’application auront également un impact sur les fournisseurs.

  • https://github.com/dotnet/efcore/pull/14022
    • Suppression des API obsolètes et surcharges de paramètres facultatifs réduites
    • Suppression de DatabaseColumn.GetUnderlyingStoreType()
  • https://github.com/dotnet/efcore/pull/14589
    • Suppression des API obsolètes
  • https://github.com/dotnet/efcore/pull/15044
    • Les sous-classes de CharTypeMapping peuvent avoir été rompues en raison des modifications de comportement requises pour résoudre quelques bogues dans l’implémentation de base.
  • https://github.com/dotnet/efcore/pull/15090
    • Ajout d’une classe de base pour IDatabaseModelFactory et mise à jour pour utiliser un objet paramètre pour atténuer les interruptions futures.
  • https://github.com/dotnet/efcore/pull/15123
    • Utilisation d’objets paramètre dans MigrationsSqlGenerator pour atténuer les interruptions futures.
  • https://github.com/dotnet/efcore/pull/14972
    • La configuration explicite des niveaux de journal a nécessité certaines modifications sur les API que les fournisseurs peuvent utiliser. Plus précisément, si les fournisseurs utilisent directement l’infrastructure de journalisation, alors cette modification peut interrompre cette utilisation. En outre, les fournisseurs qui utilisent l’infrastructure (qui sera publique) devront dériver LoggingDefinitions ou RelationalLoggingDefinitions. Consultez les fournisseurs SQL Server et en mémoire pour obtenir des exemples.
  • https://github.com/dotnet/efcore/pull/15091
    • Les chaînes de ressources Core, Relational et Abstractions sont désormais publiques.
    • CoreLoggerExtensions et RelationalLoggerExtensions sont maintenant publics. Les fournisseurs doivent utiliser ces API lors de la journalisation des évènements définis au niveau principal ou relationnel. N’accédez pas directement aux ressources de journalisation ; celles-ci sont toujours internes.
    • IRawSqlCommandBuilder est passé d’un service singleton à un service délimité
    • IMigrationsSqlGenerator est passé d’un service singleton à un service délimité
  • https://github.com/dotnet/efcore/pull/14706
    • L’infrastructure de génération de commandes relationnelles a été rendue publique afin qu’elle puisse être utilisée en toute sécurité par les fournisseurs et être légèrement refactorisée.
  • https://github.com/dotnet/efcore/pull/14733
    • ILazyLoader est passé d’un service délimité à un service temporaire
  • https://github.com/dotnet/efcore/pull/14610
    • IUpdateSqlGenerator est passé d’un service délimité à un service singleton
    • En outre, ISingletonUpdateSqlGenerator a été supprimé
  • https://github.com/dotnet/efcore/pull/15067
    • Un grand nombre du code interne utilisé par les fournisseurs a été rendu public
    • Il ne doit plus être nécessaire de référencer IndentedStringBuilder, car il a été exclus des endroits qui l’ont exposé
    • Les utilisations de NonCapturingLazyInitializer doivent être remplacées par LazyInitializer depuis la BCL
  • https://github.com/dotnet/efcore/pull/14608
    • Cette modification est entièrement abordée dans le document des changements cassants de l’application. Pour les fournisseurs, cela peut avoir un impact plus important, car tester EF Core peut souvent entraîner l’apparition de ce problème, de sorte que l’infrastructure de test a changé pour rendre cela moins probable.
  • https://github.com/dotnet/efcore/issues/13961
    • EntityMaterializerSource a été simplifié
  • https://github.com/dotnet/efcore/pull/14895
    • La traduction StartsWith a changé d’une manière à laquelle les fournisseurs peuvent vouloir/avoir besoin de réagir
  • https://github.com/dotnet/efcore/pull/15168
    • Les services des ensembles de conventions ont changé. Les fournisseurs doivent maintenant hériter de « ProviderConventionSet » ou de « RelationalConventionSet ».
    • Les personnalisations peuvent être ajoutées via des services IConventionSetCustomizer, mais elles sont destinées à être utilisées par d’autres extensions, et non par des fournisseurs.
    • Les conventions utilisées au moment de l’exécution doivent être résolues depuis IConventionSetBuilder.
  • https://github.com/dotnet/efcore/pull/15288
    • L’amorçage des données a été refactorisé dans une API publique pour éviter d’avoir à utiliser des types internes. Cela ne doit impacter que les fournisseurs non relationnels, car l’amorçage est géré par la classe relationnelle de base pour tous les fournisseurs relationnels.

2.1 ---> 2.2

Modifications des tests uniquement

  • https://github.com/dotnet/efcore/pull/12057 : autoriser les délimiteurs SQL personnalisables dans les tests
    • Modifications de test qui autorisent des comparaisons à virgule flottante non strictes dans BuiltInDataTypesTestBase
    • Modifications de test qui permettent aux tests de requête d’être réutilisés avec différents délimiteurs SQL
  • https://github.com/dotnet/efcore/pull/12072 : ajout des tests DbFunction aux tests de spécification relationnelle
    • Ainsi, ces tests peuvent être exécutés sur tous les fournisseurs de base de données
  • https://github.com/dotnet/efcore/pull/12362 : nettoyage de test asynchrone
    • Suppression des appels Wait, des asynchrones inutile et changement de nom de certaines méthodes de test
  • https://github.com/dotnet/efcore/pull/12666 : unification de l’infrastructure de test de journalisation
    • Ajout de CreateListLoggerFactory et suppression de certaines infrastructures de journalisation précédentes, ce qui nécessitera que les fournisseurs utilisant ces tests réagissent
  • https://github.com/dotnet/efcore/pull/12500 : exécution d’autres tests de requête de manière synchrone et asynchrone
    • Les noms de test et la factorisation ont changé, ce qui nécessitera que les fournisseurs utilisant ces tests réagissent
  • https://github.com/dotnet/efcore/pull/12766 : changement de nom des navigations dans le modèle ComplexNavigations
    • Les fournisseurs qui utilisent ces tests peuvent avoir besoin de réagir
  • https://github.com/dotnet/efcore/pull/12141 : renvoi du contexte au pool au lieu de le mettre à disposition dans les tests fonctionnels
    • Cette modification inclut une refactorisation de test qui peut nécessiter que les fournisseurs réagissent

Modifications de code de test et de produit

  • https://github.com/dotnet/efcore/pull/12109 : consolidation des méthodes RelationalTypeMapping.Clone
    • Les modifications apportées à la version 2.1 de RelationalTypeMapping sont autorisées pour une simplification dans les classes dérivées. Nous ne croyons pas que cela a été cassant pour les fournisseurs, mais ceux-ci peuvent exploiter cette modification dans leurs classes de mappage de types dérivées.
  • https://github.com/dotnet/efcore/pull/12069 : étiquetage ou nommage de requêtes
    • Ajoute l’infrastructure pour l’étiquetage des requêtes LINQ et l’affichage de ces étiquettes en tant que commentaires dans SQL. Cela peut nécessiter que les fournisseurs réagissent dans la génération SQL.
  • https://github.com/dotnet/efcore/pull/13115 : prise en charge des données spatiales via NTS
    • Permet aux mappages de types et aux traducteurs membres d’être inscrits en dehors du fournisseur
      • Les fournisseurs doivent appeler base.FindMapping() dans leur implémentation ITypeMappingSource pour qu’elle fonctionne
    • Suivez ce modèle pour ajouter une prise en charge spatiale à votre fournisseur qui soit cohérente entre les fournisseurs.
  • https://github.com/dotnet/efcore/pull/13199 : ajout d’un débogage amélioré à la création du fournisseur de service
    • Permet à DbContextOptionsExtensions d’implémenter une nouvelle interface qui peut aider les utilisateurs à comprendre pourquoi le fournisseur de services interne est régénéré
  • https://github.com/dotnet/efcore/pull/13289 : ajout de l’API CanConnect à utiliser par les vérifications d’intégrité
    • Cette demande de tirage (pull request) ajoute le concept CanConnect qui sera utilisé par les vérifications d’intégrité ASP.NET Core pour déterminer si la base de données est disponible. Par défaut, l’implémentation relationnelle appelle uniquement Exist, mais les fournisseurs peuvent implémenter autre chose si nécessaire. Les fournisseurs non relationnels devront implémenter la nouvelle API afin que la vérification d’intégrité soit utilisable.
  • https://github.com/dotnet/efcore/pull/13306 : mise à jour du RelationalTypeMapping de base pour ne pas définir DbParameter Size
    • Arrêt de la définition de Size par défaut, car elle peut provoquer la troncation. Les fournisseurs peuvent avoir besoin d’ajouter leur propre logique si Size doit être défini.
  • https://github.com/dotnet/efcore/pull/13372 : RevEng : toujours spécifier le type de colonne pour les colonnes décimales
    • Configurez toujours le type de colonne pour les colonnes décimales dans le code généré automatiquement plutôt que de les configurer par convention.
    • Les fournisseurs ne doivent pas avoir besoin de modifications de leur côté.
  • https://github.com/dotnet/efcore/pull/13469 : ajout de CaseExpression pour générer des expressions SQL CASE
  • https://github.com/dotnet/efcore/pull/13648 : ajout de la possibilité de spécifier des mappages de types sur SqlFunctionExpression pour améliorer l’inférence de type de magasin des arguments et des résultats.