Kit de développement logiciel (SDK) Java Azure Cosmos DB pour NoSQL (hérité) : notes de publication et ressources

  • Article

S’APPLIQUE À : NoSQL

Cet article décrit le Kit de développement logiciel (SDK) Java De synchronisation Azure Cosmos DB v2 pour l’API pour NoSQL. Cette API prend uniquement en charge les opérations synchrones.

Important

Il ne s’agit pas du Kit de développement logiciel (SDK) Java pour Azure Cosmos DB le plus récent. Nous vous recommandons vivement d’utiliser le SDK Java Azure Cosmos DB v4 pour votre projet. Suivez les instructions fournies dans les guides Migrer vers le Kit de développement logiciel (SDK) Java v4 Azure Cosmos DB et Reactor contre RxJava pour la mise à niveau.

Avertissement

Depuis le 29 février 2024, le Kit de développement logiciel (SDK) Java De synchronisation Azure Cosmos DB v2.x est désormais mis hors service. Azure Cosmos DB ne fournit plus de maintenance ni de prise en charge pour ce KIT de développement logiciel (SDK) après la mise hors service. Suivez les instructions ci-dessous pour migrer vers le Kit de développement logiciel (SDK) Java Azure Cosmos DB v4.

Liens
Téléchargement du Kit de développement logiciel (SDK) Maven
Documentation de l’API Documentation de référence sur l’API Java
Contribution au Kit de développement logiciel (SDK) GitHub
Prise en main Bien démarrer avec le Kit de développement logiciel (SDK) Java
Didacticiel d’application web Développement d’applications web avec Azure Cosmos DB
Runtime minimal pris en charge Kit de développement Java (JDK) 7+

Notes de publication

Voici les notes de publication de chaque version du Kit de développement logiciel (SDK).

2.6.5

  • Suppression de la dépendance de test com.google.guava/guava en raison de failles de sécurité
  • Mise à niveau de la dépendance com.fasterxml.jackson.core/jackson-databind vers la version 2.14.0
  • Mise à niveau de la dépendance commons-codec/commons-codec vers la version 1.15
  • Mise à niveau de la dépendance org.json/json vers la version 20180130

2.6.4

  • Correction de la stratégie de nouvelle tentative pour les délais d’expiration de lecture

2.6.3

  • Correction d’une stratégie de nouvelles tentatives quand GoneException est encapsulé dans IllegalStateException : cette modification est nécessaire de sorte que le cache de la passerelle soit actualisé sur 410 et que le connecteur Spark (pour Spark 2.4) puisse utiliser une stratégie personnalisée de nouvelles tentatives permettant aux requêtes de réussir pendant les fractionnements de partitions.

2.6.2

  • Ajout d’une nouvelle stratégie de nouvelles tentatives en cas de dépassement du délai d’attente de lecture
  • Mise à niveau de la dépendance com.fasterxml.jackson.core/jackson-databind vers la version 2.9.10.8.
  • Mise à niveau de la dépendance org.apache.httpcomponents/httpclient vers la version 4.5.13.

2.6.1

  • Correction d’un bogue dans la gestion d’une requête via l’interopérabilité du service.

2.6.0

  • Ajout de la prise en charge de l’interrogation du flux de modification à partir d’un point dans le temps.

2.5.1

  • Corrige le problème de cache de partition principale sur la requête documentCollection.

2.5.0

  • Ajout de la prise en charge de la configuration personnalisée de nouvelle tentative 449.

2.4.7

  • Corrige le problème de délai d’attente du pool de connexions.
  • Corrige l’actualisation des jetons d’authentification en cas de nouvelles tentatives internes.

2.4.6

  • Mise à jour de la bonne étiquette de stratégie de réplica côté client sur databaseAccount et mise à jour des lectures de configuration databaseAccount à partir du cache.

2.4.5

  • Si l’utilisateur fournit pkRangeId, cette version évite de réessayer sur une erreur de plage de clés de partition non valide

2.4.4

  • Actualisations du cache des plages de clés de partition optimisées.
  • Résout le scénario dans lequel le kit SDK n’a pas d’indicateur de fractionnement de partition du serveur et entraîne incorrectement l’actualisation des caches de routage côté client.

2.4.2

  • Actualisations optimisées du cache de collection.

2.4.1

  • Ajout de la prise en charge de la récupération du message d’exception interne de la chaîne de diagnostic de la requête.

2.4.0

  • Introduction de l’API de version sur PartitionKeyDefinition.

2.3.0

  • Ajout de la prise en charge des délais d’attente distincts pour le mode direct.

2.2.3

  • Utilisation d’un message d’erreur null du service et production d’une exception client de document.

2.2.2

  • Amélioration de la connexion au socket, ajout de SoKeepAlive par défaut sur true.

2.2.0

  • Ajout de la prise en charge des chaînes de diagnostic des requêtes.

2.1.3

  • Correction d’un bogue dans PartitionKey pour Hash V2.

2.1.2

  • Ajout de la prise en charge des index composites.
  • Correction d’un bogue dans le gestionnaire global des points de terminaison pour forcer le rafraîchissement.
  • Correction d’un bogue pour les opérations upsert avec des conditions préalables en mode direct.

2.1.1

  • Correction d’un bogue dans le cache d’adresse de la passerelle.

2.1.0

  • Prise en charge des écritures multirégions ajoutée pour le mode direct.
  • Ajout de la prise en charge de la gestion IOExceptions levée en tant qu’exceptions ServiceUnavailable à partir d’un proxy.
  • Correction d’un bogue dans la stratégie de nouvelle tentative de découverte de point de terminaison.
  • Correction d’un bogue pour garantir que les exceptions de pointeur Null ne sont pas levées dans BaseDatabaseAccountConfigurationProvider.
  • Correction d’un bogue pour garantir que QueryIterator ne retourne pas de valeurs Null.
  • Correction d’un bogue pour garantir que la grande partitionKey est autorisée.

2.0.0

  • Prise en charge des écritures multirégions ajoutée pour le mode passerelle.

1.16.4

  • Correction d’un bogue dans les plages de clés de partition en lecture pour une requête.

1.16.3

  • Correction d’un bogue au niveau de la définition de la taille de l’en-tête du jeton de continuation en mode DirectHttps.

1.16.2

  • Ajout de la prise en charge du basculement de streaming.
  • Ajout de la prise en charge des métadonnées personnalisées.
  • Amélioration de la logique de gestion de session.
  • Correction d’un bogue dans le cache de plage de clés de partition.
  • Correction d’un NullPointerException bogue (NPE) en mode direct.

1.16.1

  • Ajout de la prise en charge de l’index unique.
  • Possibilité de limiter la taille du jeton de continuation dans les options de flux.
  • Correction d’un bogue dans la sérialisation Json (timestamp).
  • Correction d’un bogue dans la sérialisation Json (enum).
  • Dépendance à com.fasterxml.jackson.core:jackson-databind mise au niveau de version 2.9.5.

1.16.0

  • Amélioration du regroupement de connexions pour le mode Direct.
  • Amélioration de l’amélioration de la prérécupération pour la requête de partition croisée nonorderby.
  • Amélioration de la génération d’UUID.
  • Amélioration de la logique de cohérence de session.
  • Ajout de la prise en charge de multipolygones.
  • Ajout de la prise en charge des statistiques de plage de clés de partition pour la collecte.
  • Correction d’un bogue dans la prise en charge de plusieurs régions.

1.15.0

  • Amélioration des performances de la sérialisation Json.
  • Cette version du SDK nécessite la dernière version de l’émulateur Azure Cosmos DB.

1.14.0

  • Changements internes concernant les bibliothèques Microsoft.

1.13.0

  • Correction d’un problème de lecture des plages de clés de partition uniques.
  • Correction d’un problème d’analyse d’ID de ressource affectant les bases de données avec des noms courts.
  • Correction d’un problème dû à l’encodage des clés de partition.

1.12.0

  • Correctifs de bogues critiques pour demander le traitement lors de fractionnements de partition.
  • Correction d’un problème avec les niveaux de cohérence Strong et BoundedStaleness.

1.11.0

  • Prise en charge ajoutée pour un nouveau niveau de cohérence nommé ConsistentPrefix.
  • Correction d’un bogue de lecture de collection en mode de session.

1.10.0

  • Activation de la prise en charge de la collection partitionnée avec au minimum 2 500 RU/seconde et des incréments d’évolution de 100 RU/seconde.
  • Corrige un bogue dans l’assembly natif, ce qui peut entraîner une exception NullRef dans certaines requêtes.

1.9.6

  • Correction d’un bogue dans la configuration du moteur de requête susceptible d’entraîner des exceptions pour les requêtes en mode passerelle.
  • Correction de quelques bogues dans le conteneur de session qui peuvent entraîner une exception « Ressource propriétaire introuvable » pour les requêtes immédiatement après la création de la collection.

1.9.5

  • Ajout de la prise en charge des requêtes d’agrégation (COUNT, MIN, MAX, SUM et AVG).
  • Ajout de la prise en charge de la modification de flux.
  • Ajout de la prise en charge des informations relatives aux quotas de collections via RequestOptions.setPopulateQuotaInfo.
  • Ajout de la prise en charge de l’enregistrement de script de procédure stockée via RequestOptions.setScriptLoggingEnabled.
  • Correction d’un bogue dans lequel la requête en mode DirectHttps peut cesser de répondre lors de la rencontre d’échecs de limitation.
  • Correction d’un bogue dans le mode de cohérence de session.
  • Corrige un bogue, ce qui peut entraîner la création de NullReferenceException dans HttpContext lorsque le taux de requêtes est élevé.
  • Amélioration des performances du mode DirectHttps.

1.9.4

  • Ajout de la prise en charge simple d’un proxy basé sur les instances d’un client avec l’API ConnectionPolicy.setProxy().
  • Ajout de l’API DocumentClient.close() pour fermer correctement une instance DocumentClient.
  • Amélioration des performances de requête en mode de connectivité directe en dérivant le plan de requête à partir de l’assembly natif au lieu de la passerelle.
  • Définissez FAIL_ON_UNKNOWN_PROPERTIES = false afin que les utilisateurs n’ont pas besoin de définir JsonIgnoreProperties dans leur objet Java ancien brut (POJO).
  • Journalisation refactorisée pour utiliser SLF4J.
  • Correction de quelques autres bogues dans un lecteur de cohérence.

1.9.3

  • Correction d’un bogue dans la gestion des connexions pour éviter les fuites de connexion en mode de connectivité directe.
  • Correction d’un bogue dans la requête TOP où elle pouvait lever l’exception NullReference.
  • Amélioration des performances en réduisant le nombre d’appels réseau pour les caches internes.
  • Ajout du code d’état, de l’ACTIVITYID et de l’URI de requête dans DocumentClientException pour une meilleure résolution des problèmes.

1.9.2

  • Résolution d’un problème de gestion des connexions pour plus de stabilité.

1.9.1

  • Ajout de la prise en charge du niveau de cohérence BoundedStaleness.
  • Ajout de la prise en charge de la connectivité directe pour les opérations CRUD pour les collections partitionnées.
  • Correction d’un bogue dans l’interrogation d’une base de données avec SQL.
  • Correction d’un bogue dans le cache de session où le jeton de session peut être défini de manière incorrecte.

1.9.0

  • Ajout de la prise en charge des requêtes parallèles sur plusieurs partitions.
  • Ajout de la prise en charge des requêtes TOP/ORDER BY pour les collections partitionnées.
  • Ajout de la prise en charge de la cohérence forte.
  • Ajout de la prise en charge des requêtes en fonction du nom lors de l’utilisation de la connectivité directe.
  • Correction visant à rendre ActivityId cohérent entre toutes les nouvelles tentatives de requête.
  • Correction d’un bogue lié au cache de session lors de la nouvelle création d’une collection avec le même nom.
  • Ajout des types de données Polygone et LineString lors de la spécification de la stratégie d’indexation de collection pour les requêtes spatiales à délimitation géographique.
  • Résolution des problèmes liés à Java Doc pour Java 1.8.

1.8.1

  • Correction d’un bogue dans PartitionKeyDefinitionMap pour la mise en cache de collections de partitions uniques, sans aucune extraction supplémentaire des demandes de clés de partition.
  • Correction d’un bogue pour l’absence de nouvelle tentative en cas de valeur de clé de partition incorrecte.

1.8.0

  • Ajout de la prise en charge des comptes de base de données de plusieurs régions.
  • Ajout de la prise en charge d’une nouvelle tentative automatique sur les requêtes limitées avec options de personnalisation du nombre maximum de tentatives et du délai d’attente maximum entre deux tentatives. Pour plus d’informations, consultez RetryOptions et Connecter ionPolicy.getRetryOptions().
  • Propriété IPartitionResolver déconseillée basée sur un code de partitionnement personnalisé. Utilisez des collections partitionnée pour un stockage et un débit plus élevés.

1.7.1

  • Ajout de la prise en charge d’une stratégie de nouvelle tentative pour la limitation du débit.

1.7.0

  • Ajout de la prise en charge de la durée de vie (TTL) pour les documents.

1.6.0

1.5.1

  • Correction d’un bogue dans HashPartitionResolver pour générer des valeurs de hachage en little-endian afin qu’elles soient cohérentes avec d’autres kits de développement logiciel (SDK).

1.5.0

  • Ajoutez des programmes de résolution de partitions par hachage et par spécification de plages de valeurs pour vous aider lors du partitionnement des applications sur plusieurs partitions.

1.4.0

  • Implémentation de l’opération Upsert. Nouvelles méthodes upsertXXX ajoutées pour prendre en charge la fonctionnalité Upsert.
  • Implémenter l'ID en fonction du routage. Aucune modification d'API publique, toutes les modifications en interne.

1.3.0

  • Version ignorée pour aligner le numéro de version avec les autres Kits de développement logiciel (SDK)

1.2.0

  • Prend en charge l’index géospatial.
  • Validation de la propriété ID pour toutes les ressources. Les ID des ressources ne peuvent pas contenir ?, , /#, \, caractères ou se terminer par un espace.
  • Ajoute le nouvel en-tête « progression de la transformation de l'index » à ResourceResponse.

1.1.0

  • Implémente la stratégie d'indexation V2

1.0.0

  • Kit SDK GA

Dates de lancement et de suppression

Microsoft envoie une notification au moins 12 mois avant le retrait d’un Kit de développement logiciel (SDK) pour faciliter la transition vers une version plus récente/prise en charge. Les nouvelles fonctionnalités et optimisations sont ajoutées uniquement au SDK actuel. Nous vous recommandons de toujours effectuer une mise à niveau vers la dernière version du Kit de développement logiciel (SDK) dès que possible.

Avertissement

Une fois que 30 peut être 2020, Azure Cosmos DB n’apporte plus de correctifs de bogues, ajoute de nouvelles fonctionnalités et fournit une prise en charge des versions 1.x du Kit de développement logiciel (SDK) Java Azure Cosmos DB pour l’API pour NoSQL. Si vous préférez ne pas effectuer la mise à niveau, les requêtes envoyées depuis la version 1.x du Kit de développement logiciel (SDK) continueront à être traitées par le service Azure Cosmos DB.

Après le 29 février 2016, Azure Cosmos DB n’apportera plus de correctifs de bogues, n’ajoutera plus de nouvelles fonctionnalités et ne fournira plus de support aux versions 0.x du Kit de développement logiciel (SDK) Java Azure Cosmos DB pour l’API for NoSQL. Si vous préférez ne pas effectuer la mise à niveau, les requêtes envoyées depuis la version 0.x du Kit de développement logiciel (SDK) continueront à être traitées par le service Azure Cosmos DB.

Version Date de sortie Date de suppression
2.6.1 17 décembre 2020 29 février 2024
2.6.0 16 juillet 2020 29 février 2024
2.5.1 03 juin 2020 29 février 2024
2.5.0 12 mai 2020 29 février 2024
2.4.7 20 février 2020 29 février 2024
2.4.6 24 janvier 2020 29 février 2024
2.4.5 10 novembre 2019 29 février 2024
2.4.4 24 octobre 2019 29 février 2024
2.4.2 26 septembre 2019 29 février 2024
2.4.1 18 juillet 2019 29 février 2024
2.4.0 4 mai 2019 29 février 2024
2.3.0 24 avril 2019 29 février 2024
2.2.3 16 avril 2019 29 février 2024
2.2.2 5 avril 2019 29 février 2024
2.2.0 27 mars 2019 29 février 2024
2.1.3 13 mars 2019 29 février 2024
2.1.2 9 mars 2019 29 février 2024
2.1.1 13 décembre 2018 29 février 2024
2.1.0 20 novembre 2018 29 février 2024
2.0.0 21 septembre 2018 29 février 2024
1.16.4 10 septembre 2018 30 mai 2020
1.16.3 09 septembre 2018 30 mai 2020
1.16.2 29 juin 2018 30 mai 2020
1.16.1 16 mai 2018 30 mai 2020
1.16.0 15 mars 2018 30 mai 2020
1.15.0 14 novembre 2017 30 mai 2020
1.14.0 28 octobre 2017 30 mai 2020
1.13.0 25 août 2017 30 mai 2020
1.12.0 11 juillet 2017 30 mai 2020
1.11.0 10 mai 2017 30 mai 2020
1.10.0 11 mars 2017 30 mai 2020
1.9.6 21 février 2017 30 mai 2020
1.9.5 31 janvier 2017 30 mai 2020
1.9.4 24 novembre 2016 30 mai 2020
1.9.3 30 octobre 2016 30 mai 2020
1.9.2 28 octobre 2016 30 mai 2020
1.9.1 26 octobre 2016 30 mai 2020
1.9.0 3 octobre 2016 30 mai 2020
1.8.1 30 juin 2016 30 mai 2020
1.8.0 14 juin 2016 30 mai 2020
1.7.1 30 avril 2016 30 mai 2020
1.7.0 27 avril 2016 30 mai 2020
1.6.0 29 mars 2016 30 mai 2020
1.5.1 31 décembre 2015 30 mai 2020
1.5.0 4 décembre 2015 30 mai 2020
1.4.0 5 octobre 2015 30 mai 2020
1.3.0 5 octobre 2015 30 mai 2020
1.2.0 5 août 2015 30 mai 2020
1.1.0 9 juillet 2015 30 mai 2020
1.0.1 12 mai 2015 30 mai 2020
1.0.0 7 avril 2015 30 mai 2020
0.9.5-prelease 9 mars 2015 29 février 2016
0.9.4-prelease 17 février 2015 29 février 2016
0.9.3-prelease 13 janvier 2015 29 février 2016
0.9.2-prelease 19 décembre 2014 29 février 2016
0.9.1-prelease 19 décembre 2014 29 février 2016
0.9.0-prelease 10 décembre 2014 29 février 2016

Forum Aux Questions

Comment serai-je informé du retrait du kit SDK ?

Microsoft vous avertit 12 mois à l’avance de la fin de la prise en charge d’un kit SDK mis hors service afin de favoriser une transition en douceur vers un kit SDK pris en charge. Nous vous informons via différents canaux de communication : le portail Azure, les mises à jour Azure et une communication directe avec les administrateurs de service affectés.

Pendant cette période de 12 mois, puis-je créer des applications à l’aide d’un kit SDK Azure Cosmos DB destiné à être mis hors service ?

Oui, au cours de la période de préavis de 12 mois, vous pouvez créer, déployer et modifier des applications à l’aide du kit SDK Azure Cosmos DB destiné à être mis hors service. Nous vous conseillons de migrer vers une version prise en charge plus récente du kit SDK Azure Cosmos DB pendant cette période de 12 mois, le cas échéant.

Après la date de mise hors service, qu’advient-il des applications qui utilisent le kit SDK Azure Cosmos DB non pris en charge ?

Après la date de mise hors service, Azure Cosmos DB n’apporte plus de correctifs de bogues, n’ajoute plus de nouvelles fonctionnalités et ne fournit plus de support aux versions mises hors service du kit SDK. Si vous préférez ne pas effectuer la mise à niveau, les requêtes envoyées depuis les versions mises hors service du Kit de développement logiciel (SDK) continueront d’être traitées par le service Azure Cosmos DB.

Quelles versions du kit SDK disposent des dernières fonctionnalités et mises à jour ?

Les nouvelles fonctionnalités et mises à jour ne sont ajoutées qu’à la dernière version mineure de la dernière version majeure prise en charge du kit SDK. Nous vous recommandons de toujours utiliser la dernière version pour tirer parti des nouvelles fonctionnalités, des améliorations des performances et des correctifs de bogues. Si vous utilisez une ancienne version du kit SDK encore en service, vos requêtes vers Azure Cosmos DB continuent de fonctionner, mais vous n’avez accès à aucune des nouvelles fonctionnalités.

Que faire si je ne parviens pas à mettre à jour mon application avant la date limite ?

Nous vous recommandons de mettre à niveau vers la dernière version du kit de développement logiciel dès que possible. Une fois qu’un kit SDK est marqué pour la mise hors service, vous avez 12 mois pour mettre à jour votre application. Si vous n’êtes pas en mesure de procéder à une mise à jour avant la date de mise hors service, les requêtes envoyées à partir des versions mises hors service du kit SDK continuent d’être traitées par Azure Cosmos DB. Vos applications continuent donc de fonctionner. Toutefois, Azure Cosmos DB n’apporte plus de correctifs de bogues, n’ajoute plus de nouvelles fonctionnalités et ne fournit plus de support aux versions mises hors service du kit SDK.

Si vous disposez d’un plan de support et avez besoin d’assistance technique, veuillez nous contacter en remplissant un ticket de support.

Comment puis-je demander l’ajout de fonctionnalités à un SDK ou un connecteur ?

Les nouvelles fonctionnalités ne sont pas toujours ajoutées à chaque SDK ou connecteur immédiatement. S’il existe une fonctionnalité non prise en charge que vous souhaitez ajouter, ajoutez des commentaires à notre forum communautaire.