mongo java driver
va Driver 4.11.5 (November 06, 2024)
Las notas de la versión están disponibles aquí.
La documentación API y de referencia para el controlador Java está disponible aquí.
La documentación API y de referencia para el controlador Kotlin está disponible aquí.
La documentación de referencia y API para el controlador Scala está disponible aquí.
Para obtener tutoriales sobre cómo utilizar los controladores JVM de MongoDB, consulte la Universidad de MongoDB. También se pueden encontrar tutoriales, vídeos y ejemplos de código adicionales que utilizan tanto el controlador Java como el controlador Kotlin en el Centro de desarrolladores de MongoDB.
Si tiene problemas, preguntas o comentarios sobre los controladores MongoDB Java, Kotlin y Scala, consulte nuestros canales de soporte. No envíe correos electrónicos directamente a ninguno de los desarrolladores de controladores con problemas o preguntas; es más probable que obtenga una respuesta en los foros de la comunidad de MongoDB o StackOverflow.
Como mínimo, incluya en su descripción la versión exacta del controlador que está utilizando. Si tiene problemas de conectividad, también suele ser útil pegar la línea de código donde construye la instancia de MongoClient, junto con los valores de todos los parámetros que pasa al constructor. También debe verificar los registros de su aplicación para detectar excepciones relacionadas con la conectividad y publicarlas también.
¿Crees que has encontrado un error en los controladores de Java, Kotlin o Scala? ¿Quieres ver una nueva característica en los controladores? Abra un caso en nuestra herramienta de gestión de problemas, JIRA:
Los informes de errores en JIRA para el controlador y el proyecto Core Server (es decir, SERVIDOR) son públicos .
Si ha identificado una vulnerabilidad de seguridad en un controlador o en cualquier otro proyecto de MongoDB, infórmelo de acuerdo con las instrucciones aquí.
Se producirán incrementos importantes (como 4.x -> 5.x) cuando se realicen cambios importantes en la API pública. Todos los métodos y clases eliminados en una versión principal habrán quedado obsoletos en una versión anterior de la rama de la versión principal anterior y/o se habrán mencionado de otro modo en las notas de la versión.
Se producirán incrementos menores de 5.x (como 5.1, 5.2, etc.) cuando se agreguen nuevas funciones no triviales o se produzcan mejoras significativas o correcciones de errores que puedan tener cambios de comportamiento que puedan afectar algunos casos extremos (como la dependencia del comportamiento resultante de un error). Un ejemplo de mejora es un método o clase agregado para admitir nuevas funciones agregadas al servidor MongoDB. Las versiones menores casi siempre serán compatibles binariamente con versiones menores anteriores de la misma rama de versión principal, excepto lo que se indica a continuación.
Los incrementos del parche 5.xy (como 5.0.0 -> 5.0.1, 5.1.1 -> 5.1.2, etc.) se producirán únicamente para corregir errores y siempre serán compatibles binariamente con versiones de parches anteriores de la misma rama de versión menor. .
Las API marcadas con la anotación @Alpha se encuentran en las primeras etapas de desarrollo, sujetas a cambios incompatibles, o incluso a eliminación, en una versión futura y pueden carecer de algunas características previstas. Una API que lleva la anotación @Alpha puede contener problemas conocidos que afectan la funcionalidad, el rendimiento y la estabilidad. También están exentos de cualquier garantía de compatibilidad realizada por la biblioteca que los contiene.
No es aconsejable que las aplicaciones utilicen API Alpha en entornos de producción o que las bibliotecas (que se incluyen en los CLASSPATH de los usuarios, fuera del control de los desarrolladores de la biblioteca) dependan de estas API. Las API Alpha están destinadas únicamente a fines experimentales .
Las API marcadas con la anotación @Beta a nivel de clase o método están sujetas a cambios. Pueden modificarse de cualquier forma, o incluso eliminarse, en cualquier momento. Si su código es una biblioteca en sí (es decir, se usa en CLASSPATH de usuarios fuera de su control), no debe usar API beta, a menos que las vuelva a empaquetar (por ejemplo, usando sombreado, etc.).
Las API marcadas con la anotación @Deprecated a nivel de clase o método seguirán siendo compatibles hasta la próxima versión principal, pero se recomienda dejar de usarlas.
Todo el código dentro de los paquetes com.mongodb.internal.* se considera API privada y no se debe confiar en él en absoluto. Puede cambiar en cualquier momento.
Los binarios y la información de dependencia de Maven, Gradle, Ivy y otros se pueden encontrar en http://search.maven.org.
Ejemplo para Maven:
< dependency >
< groupId >org.mongodb</ groupId >
< artifactId >mongodb-driver-sync</ artifactId >
< version >x.y.z</ version >
</ dependency >Las compilaciones de instantáneas también se publican periódicamente a través de Sonatype.
Ejemplo para Maven:
< repositories >
< repository >
< id >sonatype-snapshot</ id >
< url >https://oss.sonatype.org/content/repositories/snapshots/</ url >
</ repository >
</ repositories >Se requiere Java 17+ y git para construir y compilar el código fuente. Para construir y probar el controlador:
$ git clone https://github.com/mongodb/mongo-java-driver.git
$ cd mongo-java-driver
$ ./gradlew check
El conjunto de pruebas requiere que mongod se ejecute con enableTestCommands , que se puede configurar con el parámetro de línea de comando --setParameter enableTestCommands=1 :
$ mkdir -p data/db
$ mongod --dbpath ./data/db --logpath ./data/mongod.log --port 27017 --logappend --fork --setParameter enableTestCommands=1
Si encuentra errores "Too many open files" al ejecutar las pruebas, deberá aumentar la cantidad de descriptores de archivos disponibles antes de iniciar mongod como se describe en https://www.mongodb.com/docs/manual/reference/ulimit /
Se requieren un par de pasos de configuración manual para ejecutar el código en IntelliJ:
Se requiere Java 17+ para construir y compilar el código fuente.
Error: java: cannot find symbol: class SNIHostName location: package javax.net.ssl
Solución: Configuración/Preferencias > Compilación, Ejecución, Implementación > Compilador > Compilador Java - desmarque "Usar la opción '--release' para compilación cruzada (Java 9 y posterior)"
Error: java: package com.mongodb.internal.build does not exist
Correcciones: Cualquiera de los siguientes:
generateBuildConfig : por ejemplo: ./gradlew generateBuildConfig o mediante Gradle > driver-core > Tasks > buildconfig > generateBuildConfiggenerateBuildConfig para que se ejecute antes de la compilación. a través de Gradle > Tareas > buildconfig > haga clic con el botón derecho en generateBuildConfig - haga clic en "Ejecutar antes de compilar"
