Overview
En esta sección, puedes identificar los cambios que podrías necesitar realizar en tu aplicación para actualizar tu driver a una nueva versión.
Antes de actualizar, realiza las siguientes acciones:
Asegúrese de que la nueva versión sea compatible con las versiones de MongoDB Server a las que se conecta su aplicación y con el Entorno de Ejecución de Java (JRE) en el que se ejecuta su aplicación. Consulta la Compatibilidad página para esta información.
Abordar cualquier cambio disruptivo entre la versión actual del driver que utiliza su aplicación y la versión de actualización planificada en la sección Cambios disruptivos. Para aprender más sobre los cambios de compatibilidad con la liberación del MongoDB Server, consulta la sección Cambios de compatibilidad con la liberación del servidor.
Tip
Para minimizar la cantidad de cambios que su aplicación podría requerir al actualizar versiones del controlador en el futuro, utilice la Stable API.
cambio disruptivo
Un cambio disruptivo es una modificación en una convención o comportamiento en una versión específica del driver que podría impedir que tu aplicación funcione correctamente si no se aborda antes de actualizarla.
Los cambios disruptivos en esta sección están categorizados según la versión del controlador que los introdujo. Al actualizar las versiones de los drivers, solucione todos los cambios disruptivos entre la versión actual y la versión actualizada. Por ejemplo, si está actualizando el controlador de la versión 4.0 a la 4.5, atienda todos los cambios disruptivos de la versión posterior a la v4.0, incluyendo cualquiera que esté en la lista bajo v4.5.
Versión 5.5 cambio disruptivo
El driver ya no es compatible con la versión v4.0 de MongoDB Server. Para obtener más información sobre este cambio, consulte la sección Cambios en el soporte de versión de controlador 5.5 para servidores.
Versión 5.2 cambio disruptivo
El driver ya no es compatible con la versión v3.6 de MongoDB Server. Para obtener más información sobre este cambio, consulte la sección Cambios en el soporte de versión de controlador 5.2 para servidores.
Version 5.0 Cambios disruptivos
Esta versión del driver introduce los siguientes cambios disruptivos:
Introduce los siguientes cambios a la
ConnectionIdclase:El constructor
ConnectionIdahora acepta un valor de tipolongcomo su segundo parámetro en lugar del tipoint. De manera similar, el constructor ahora acepta un valor de tipoLongcomo su tercer parámetro en lugar de tipoInteger. Debido a que este cambio rompe la compatibilidad binaria, recompila cualquier código existente que llame al constructorConnectionId.El método
withServerValue()ahora acepta un parámetro de tipolongen lugar de tipoint. Este cambio rompe la compatibilidad binaria, por lo que debes recompilar cualquier código que llame al métodowithServerValue().El método
getServerValue()ahora regresa un valor de tipoLongen vez de tipoInteger. De manera similar, el métodogetLocalValue()devuelve un valor de tipolongen lugar de tipoint. Dado que este cambio rompe tanto la compatibilidad binaria como la de origen, actualice cualquier código fuente que utilice estos métodos y vuelva a compilar su binario.
Reemplaza las siguientes anotaciones de registros del paquete
org.bson.codecs.record.annotationscon anotaciones del mismo nombre del paqueteorg.bson.codecs.pojo.annotations:BsonIdBsonPropertyBsonRepresentation
Cambia el tipo de dato del parámetro de duración de tiempo de espera en los métodos
SocketSettings.Builder.connectTimeout()ySocketSettings.Builder.readTimeout(). El tipo de dato de este parámetro es ahoralongen lugar deint.En versiones anteriores, este parámetro es de tipo
intpara ambos métodos. Este cambio interrumpe la compatibilidad binaria y requiere la recompilación, pero no requiere cambios en el código. Para ver un ejemplo que muestra cómo llamar a los métodosSocketSettings, consulte el Ejemplo SocketSettings en la guía Especificar la configuración de MongoClient.Elimina el método
Filters.eqFull(), lanzado exclusivamente enBeta, que permitía construir un filtro de igualdad al realizar una MongoDB Vector Search. Puedes usar el métodoFilters.eq()al instanciar un tipoVectorSearchOptions, como se muestra en el siguiente código:VectorSearchOptions opts = vectorSearchOptions().filter(eq("x", 8));
Elimina la clase implícita
org.mongodb.scala.ObservableImplicits.ToSingleObservableVoid. Esto significa que el tipoorg.reactivestreams.Publisher[Void]ya no se convierte automáticamente aorg.mongodb.scala.SingleObservable[Void]. La API también exponeorg.mongodb.scala.Observable[Unit]en lugar deorg.mongodb.scala.Observable[Void].Para obtener más información, consulte el Observable trait en la documentación de Scala API.
Cambia la forma en que
ClusterSettingscalculaClusterConnectionMode, haciéndolo más coherente al utilizar el nombre del set de réplicas especificado, independientemente de cómo esté configurado. Anteriormente, el nombre de set de réplicas solo se consideraba si lo establecía la cadena de conexión.Por ejemplo, en las siguientes dos muestras de código ambos devuelven el valor
ClusterConnectionMode.MULTIPLE, mientras que anteriormente el segundo devolvíaClusterConnectionMode.SINGLE.ClusterSettings.builder() .applyConnectionString(new ConnectionString("mongodb://127.0.0.1:27017/?replicaSet=replset")) .build() .getMode() ClusterSettings.builder() .hosts(Collections.singletonList( new ServerAddress("127.0.0.1", 27017) )) .requiredReplicaSetName("replset") .build() .getMode() Cambia cómo los valores
BsonDecimal128responden a las llamadas de métodos, al responder de la misma manera que los valoresDecimal128. En particular,BsonDecimal128.isNumber()ahora devuelvetrue, yBsonDecimal128.asNumber()devuelve el equivalenteBsonNumber.Remueve los métodos ServerAddress
getSocketAddress()ygetSocketAddresses().En lugar de
getSocketAddress(), utiliza el método de instanciagetByName()dejava.net.InetAddress.En lugar de
getSocketAddresses(), utiliza el método de instanciagetAllByName()dejava.net.InetAddress.Remueve los métodos UnixServerAddress
getSocketAddress()ygetUnixSocketAddress().En lugar de
getUnixSocketAddress(), construya una instancia dejnr.unixsocket.UnixSocketAddress. Pasar la ruta completa del archivo del socket UNIX al constructor. Por defecto, MongoDB crea un archivo de socket UNIX situado en"/tmp/mongodb-27017.sock". Para obtener más información sobre elUnixSocketAddress, consulta la documentación de la API UnixSocketAddress.Remueve la interfaz
Parameterizable. En lugar de implementar esta interfaz en un tipoCodecpersonalizado, sobrescriba el métodoCodecProvider.get()en elCodecProviderdel códec si el códec está destinado a un tipo parametrizado.Remueve el método
isSlaveOk()de las clasesReadPreferenceyTaggableReadPreference. Para comprobar si una preferencia de lectura permite leer de un miembro secundario de un set de réplicas, use losisSecondaryOk()métodos de estas clases en su lugar.Elimina los métodos asistentes
DBCollection.getStats()yDBCollection.isCapped()para el comandocollStats. En lugar de estos métodos, puedes usar la etapa del pipeline de agregación$collStats. Para obtener un ejemplo de cómo utilizar esta etapa de la pipeline, consulta Novedades en 4.11 para el driver de Java.Elimina las clases
MapCodecyIterableCodec. En lugar deMapCodec, se debe usarMapCodecProvider. En lugar deIterableCodec, usarCollectionCodecProvider, oIterableCodecProviderpara los tiposIterableque no sean tiposCollection.Remueve los métodos
sharded()ynonAtomic()de las clasesMapReducePublisheryMapReduceIterable.Elimina los siguientes métodos para su uso con índices
geoHaystack:Indexes.geoHaystack()IndexOptions.getBucketSize()IndexOptions.bucketSize()
En su lugar, puedes usar la etapa del pipeline de agregación
$geoNearo un operador del query geoespacial en un índice 2d. Para obtener más información, consulta la página de consultas geoespaciales en el manual de MongoDB Server.Elimina la opción
oplogReplayde las operaciones de búsqueda. Esto incluye los siguientes métodos:DBCursor.oplogReplay()DBCollectionFindOptions.isOplogReplay()DBCollectionFindOptions.oplogReplay()FindPublisher.oplogReplay()FindIterable.oplogReplay()
Elimina los siguientes constructores
Exception:MongoBulkWriteException(BulkWriteResult, List<BulkWriteError>, WriteConcernError, ServerAddress)MongoCursorNotFoundException(long, ServerAddress)MongoQueryException(ServerAddress, int, String)MongoQueryException(ServerAddress, int, String, String)MongoQueryException(MongoCommandException)
Remueve las siguientes sobrecargas para el método
BulkWriteResult.acknowledged():acknowledged(Type, int, List<BulkWriteUpsert>)acknowledged(Type, int, Integer, List<BulkWriteUpsert>)acknowledged(int, int, int, Integer, List<BulkWriteUpsert>)
Elimina los siguientes constructores
ChangeStreamDocument:ChangeStreamDocument(String, BsonDocument, BsonDocument, BsonDocument, TDocument, TDocument, BsonDocument, ...)ChangeStreamDocument(String, BsonDocument, BsonDocument, BsonDocument, TDocument, BsonDocument, BsonTimestamp, ...)ChangeStreamDocument(OperationType, BsonDocument, BsonDocument, BsonDocument, TDocument, BsonDocument, BsonTimestamp, ...)
Se remueven los siguientes constructores para eventos:
CommandEvent(RequestContext, int, ConnectionDescription, String)CommandEvent(int, ConnectionDescription, String)CommandEvent(RequestContext, long, int, ConnectionDescription, String)CommandFailedEvent(RequestContext, int, ConnectionDescription, String, long, Throwable)CommandFailedEvent(int, ConnectionDescription, String, long, Throwable)CommandStartedEvent(RequestContext, int, ConnectionDescription, String, String, BsonDocument)CommandStartedEvent(int, ConnectionDescription, String, String, BsonDocument)CommandSucceededEvent(RequestContext, int, ConnectionDescription, String, BsonDocument, long)CommandSucceededEvent(int, ConnectionDescription, String, BsonDocument, long)ConnectionCheckedInEvent(ConnectionId)ConnectionCheckedOutEvent(ConnectionId, long)ConnectionCheckedOutEvent(ConnectionId)ConnectionCheckOutFailedEvent(ServerId, long, Reason)ConnectionCheckOutFailedEvent(ServerId, Reason)ConnectionCheckOutStartedEvent(ServerId)ConnectionReadyEvent(ConnectionId)ServerHeartbeatFailedEvent(ConnectionId, long, Throwable)ServerHeartbeatSucceededEvent(ConnectionId, BsonDocument, long)
Remueve la opción
errorLabelsde la claseWriteConcernError. Esto incluye los métodosaddLabel()ygetErrorLabels()y el constructor que incluye un parámetroerrorLabels. En su lugar, puedes utilizar las etiquetas de error incluidas en el objetoMongoExceptionque contiene elWriteConcernError.Elimina las siguientes clases del paquete
com.mongodb.event:ConnectionAddedEventConnectionPoolOpenedEventConnectionRemovedEventClusterListenerAdapterConnectionPoolListenerAdapterServerListenerAdapterServerMonitorListenerAdapter
Debido a estas eliminaciones, los siguientes métodos también se eliminaron de la interfaz
ConnectionPoolListener:connectionAddedconnectionPoolOpenedconnectionRemoved
Para obtener más información sobre el paquete de eventos, consulte la documentación del paquete com.mongodb.event
Agrega soporte para una nueva opción
authorizedCollectiondel comandolistCollections. Esto introduce un cambio binario significativo en los métodosMongoDatabase.listCollectionNames(), lo que significa que cualquier código que use estos métodos debe ser recompilado. Este cambio no requiere ninguna modificación en el código fuente.Remueve los siguientes métodos y tipos relacionados con la interfaz Stream:
streamFactoryFactory()método deMongoClientSettings.Builder. Utiliza el métodoMongoClientSettings.Builder.transportSettings()en su lugar.getStreamFactoryFactory()método deMongoClientSettings. Utiliza el métodoMongoClientSettings.getTransportSettings()en su lugar.NettyStreamFactoryFactoryclase. Utiliza elNettyTransportSettings, creable porTransportSettings.nettyBuilder()y aplicado a través deMongoClientSettings.Builder.transportSettings().NettyStreamFactoryclaseAsynchronousSocketChannelStreamFactoryclaseAsynchronousSocketChannelStreamFactoryFactoryclaseBufferProviderInterfazSocketStreamFactoryclaseStreamInterfazStreamFactoryInterfazStreamFactoryFactoryInterfazTlsChannelStreamFactoryFactoryclase
Cambios disruptivos en la versión 4.8
El driver deja de admitir la conexión a versiones del MongoDB Server v3.4 y anteriores. Para obtener más información sobre este cambio, consulta la sección Cambios en la compatibilidad con servidores de la versión del controlador 4.8 .
Debe agregar una dependencia explícita al módulo
org.bson.codecs.recordsi su aplicación implementa el controlador en un contenedor OSGi y depende del controlador para la codificación y decodificación de registros Java.El
RecordCodec, implementado en la versión 4.6, deserializó POJOs y clases de registro que se especifican como parámetros de tipo de camposListoMapde un registro como valoresDocumenten lugar de sus respectivas clases. Esta versión ahora los deserializa en los tipos de registro y POJO adecuados.Por ejemplo, las siguientes definiciones de clases de registro muestran un registro
Bookque contiene unListque recibe un parámetro de tipoChapter:public record Book(String title, List<Chapter> chapters) {} public record Chapter(Integer number, String text) {} A partir de esta versión, el códec deserializa datos en el
Listen clases de registroChapteren lugar de valoresDocument.
Cambios disruptivos en la versión 4.7
La API del generador
setWindowFieldsya no está en versión beta. El nuevo constructor rompe la compatibilidad binaria y de origen. Consulte la documentación de la API Aggregates para obtener información sobre las nuevas firmas de métodos desetWindowFields().Si tu aplicación utiliza este constructor en una versión anterior a la v4.7, actualiza tu código fuente para emplear la nueva firma de método y recompilar tu binario.
Cambios disruptivos en la versión 4.2
La clase
ObjectIdy su camposerialVersionUIDse actualizaron para utilizar un nuevo formato que minimiza los problemas de compatibilidad de serialización entre diferentes versiones del controlador.Si una aplicación que utilice esta versión o posterior del driver intenta realizar la serialización de objetos Java en cualquier objeto que contenga una
ObjectIdy que haya sido serializado por una versión anterior del driver, Java arroja unaInvalidClassException.Para aprender más sobre la Serialización de Objetos Java, consulta la documentación de Java sobre Objetos Serializables.
Versión 4.0 cambios disruptivos
En esta versión se eliminaron varias clases y métodos marcados como obsoletos en la versión 3.12.
Los métodos asistentes de inserción devuelven un objeto de resultado de inserción en lugar de
void.Los métodos
toJson()enBsonDocument,Document, yDbObjectdevuelven un formato JSON relajado en lugar de un formato JSON estricto. Esto hace que los documentos JSON sean más legibles, pero puede dificultar la identificación de la información de tipo BSON, como la diferencia entre un entero de 32 bits y uno de 64 bits. Si tu aplicación depende del formato JSON estricto, utiliza el modo estricto al leer o escribir datos. Aprende a especificar el formato JSON en la API actual en la guía Formato de datos de documento: JSON extendido.La representación BSON por defecto del valor
java.util.UUIDcambió deJAVA_LEGACYaUNSPECIFIED. Las aplicaciones que almacenan o recuperan valores UUID deben especificar explícitamente qué representación usar. Puedes especificar la representación en la propiedaduuidRepresentationdeMongoClientSettings.La representación UUID que especifiques controla estrictamente cómo el controlador decodifica los UUID. En versiones anteriores del driver, si se especificaba la representación de
JAVA_LEGACY, el driver decodificaba objetos binarios de subtipos 3 y 4 como UUIDs. En la versión 4.0, la representaciónJAVA_LEGACYfunciona solo con el subtipo 3.Para obtener una lista de nodos en el enum
UuidRepresentation, consulta la documentación de la API v4.0.El pool de conexiones ya no restringe el número de hilos de la cola de espera ni de tareas asincrónicas que requieran una conexión a MongoDB. La aplicación debe limitar las solicitudes según sea necesario en lugar de depender de que el controlador lance un
MongoWaitQueueFullException.El controlador ya no registra utilizando el paquete
java.util.logging(JUL) y solo admite el framework de registro SLF4J.Se eliminaron los drivers integrados y Android. Si tu aplicación depende de estos controladores, debes seguir usando una versión 3.x del controlador Java.
Los uber JARs,
mongo-java-driverymongodb-driver, ya no se publican. Si la aplicación depende de alguno de estos, debe cambiar amongodb-driver-syncomongodb-driver-legacydependiendo de qué API utilice la aplicación. Asegúrate de remover los JARs ybergigantes de tus dependencias.Las actualizaciones de varias clases introdujeron rupturas de compatibilidad binaria, como el cambio en la signatura del método de los métodos de inserción asistentes. Recompile todas las clases que se vinculan al driver contra esta versión o posterior para asegurarse de que sigan funcionando.
Cambios en la compatibilidad de la versión del servidor
Un cambio de compatibilidad de versión de servidor es una modificación en el MongoDB Java Driver que deja de admitir un conjunto de versiones del MongoDB Server.
El driver interrumpe el soporte para una versión de MongoDB Server después de que esta llegue a su final de vida útil (EOL).
Para obtener más información sobre el soporte de MongoDB para productos EOL, consulta la Política de soporte para versiones anteriores.
Versión del controlador 5.5 Cambios en el soporte del servidor
El controlador v5.5 deja de ser compatible con el MongoDB Server 4.0. Para utilizar el v5.5 driver, debes conectarte a MongoDB Server 4.2 o posterior. Para aprender cómo actualizar su implementación del Servidor MongoDB, vea las Notas de la versión en el manual del Servidor MongoDB.
Versión del controlador 5.2 Cambios en el soporte del servidor
El controlador v5.2 deja de ser compatible con el MongoDB Server 3.6. Para utilizar el v5.2 driver, debes conectarte a MongoDB Server 4.0 o posterior. Para aprender cómo actualizar su implementación del Servidor MongoDB, vea las Notas de la versión en el manual del Servidor MongoDB.
Versión del controlador 4.8 Cambios en el soporte del servidor
El driver v4.8 descarta el soporte para MongoDB Server 3.4 y versiones anteriores. Para utilizar el v4.8 driver, debes conectarte a MongoDB Server 3.6 o posterior. Para aprender cómo actualizar su implementación del Servidor MongoDB, vea las Notas de la versión en el manual del Servidor MongoDB.
Versión del controlador 3.x Cambios en el soporte
Las versiones 3.x del driver de Java no pueden conectarse a MongoDB Server v8.1. A partir de MongoDB Server v8.1, el comando buildinfo requiere autenticación, lo que provoca una incompatibilidad con la v3.x driver.