mongo java driver
va Driver 4.11.5 (November 06, 2024)
As notas de lançamento estão disponíveis aqui.
A documentação de referência e API para o driver Java está disponível aqui.
A documentação de referência e API para o driver Kotlin está disponível aqui.
A documentação de referência e API para o driver Scala está disponível aqui.
Para tutoriais sobre como usar os drivers JVM do MongoDB, consulte MongoDB University. Tutoriais, vídeos e exemplos de código adicionais usando o driver Java e o driver Kotlin também podem ser encontrados no MongoDB Developer Center.
Para problemas, dúvidas ou comentários sobre os drivers MongoDB Java, Kotlin e Scala, consulte nossos canais de suporte. Não envie e-mail diretamente a nenhum dos desenvolvedores de driver com problemas ou perguntas - é mais provável que você obtenha uma resposta nos Fóruns da Comunidade MongoDB ou no StackOverflow.
No mínimo, inclua na sua descrição a versão exata do driver que você está usando. Se você estiver tendo problemas de conectividade, geralmente também é útil colar a linha de código onde você constrói a instância do MongoClient, junto com os valores de todos os parâmetros que você passa para o construtor. Você também deve verificar os logs do seu aplicativo em busca de exceções relacionadas à conectividade e publicá-las também.
Você acha que encontrou um bug nos drivers Java, Kotlin ou Scala? Quer ver um novo recurso nos drivers? Abra um caso em nossa ferramenta de gerenciamento de problemas, JIRA:
Os relatórios de bugs no JIRA para o driver e o projeto Core Server (ou seja, SERVER) são públicos .
Se você identificou uma vulnerabilidade de segurança em um driver ou qualquer outro projeto do MongoDB, relate-a de acordo com as instruções aqui.
Incrementos maiores (como 4.x -> 5.x) ocorrerão quando alterações significativas forem feitas na API pública. Todos os métodos e classes removidos em uma versão principal terão sido descontinuados em uma versão anterior da ramificação da versão principal anterior e/ou mencionados de outra forma nas notas de versão.
Incrementos menores de 5.x (como 5.1, 5.2, etc.) ocorrerão quando novas funcionalidades não triviais forem adicionadas ou ocorrerem melhorias significativas ou correções de bugs que podem ter mudanças comportamentais que podem afetar alguns casos extremos (como dependência de comportamento resultante de um bug). Um exemplo de aprimoramento é um método ou classe adicionado para oferecer suporte a novas funcionalidades adicionadas ao servidor MongoDB. Lançamentos secundários quase sempre serão compatíveis com binários com lançamentos secundários anteriores do mesmo ramo de lançamento principal, exceto conforme indicado abaixo.
Os incrementos do patch 5.xy (como 5.0.0 -> 5.0.1, 5.1.1 -> 5.1.2, etc) ocorrerão apenas para correções de bugs e sempre serão compatíveis com binários com versões de patch anteriores do mesmo branch de lançamento secundário .
APIs marcadas com a anotação @Alpha estão nos estágios iniciais de desenvolvimento, sujeitas a alterações incompatíveis, ou mesmo remoção, em uma versão futura e podem não ter alguns recursos pretendidos. Uma API com a anotação @Alpha pode conter problemas conhecidos que afetam a funcionalidade, o desempenho e a estabilidade. Eles também estão isentos de quaisquer garantias de compatibilidade feitas pela biblioteca que os contém.
Não é aconselhável que aplicações utilizem APIs Alpha em ambientes de produção ou que bibliotecas (que são incluídas nos CLASSPATHs dos usuários, fora do controle dos desenvolvedores da biblioteca) dependam dessas APIs. As APIs Alpha destinam-se apenas a fins experimentais .
APIs marcadas com a anotação @Beta no nível de classe ou método estão sujeitas a alterações. Eles podem ser modificados de qualquer forma, ou mesmo removidos, a qualquer momento. Se o seu código for uma biblioteca em si (ou seja, for usado no CLASSPATH de usuários fora do seu controle), você não deverá usar APIs beta, a menos que você as reempacote (por exemplo, usando sombreamento, etc.).
APIs marcadas com a anotação @Deprecated no nível de classe ou método permanecerão suportadas até a próxima versão principal, mas é recomendado parar de usá-las.
Todo o código dentro dos pacotes com.mongodb.internal.* é considerado API privada e não deve ser considerado confiável. Isso pode mudar a qualquer momento.
Binários e informações de dependência para Maven, Gradle, Ivy e outros podem ser encontrados em http://search.maven.org.
Exemplo para Maven:
< dependency >
< groupId >org.mongodb</ groupId >
< artifactId >mongodb-driver-sync</ artifactId >
< version >x.y.z</ version >
</ dependency >As compilações de instantâneos também são publicadas regularmente via Sonatype.
Exemplo para Maven:
< repositories >
< repository >
< id >sonatype-snapshot</ id >
< url >https://oss.sonatype.org/content/repositories/snapshots/</ url >
</ repository >
</ repositories >Java 17+ e git são necessários para construir e compilar o código-fonte. Para construir e testar o driver:
$ git clone https://github.com/mongodb/mongo-java-driver.git
$ cd mongo-java-driver
$ ./gradlew check
O conjunto de testes requer que o mongod esteja em execução com enableTestCommands , que pode ser definido com o parâmetro de linha de comando --setParameter enableTestCommands=1 :
$ mkdir -p data/db
$ mongod --dbpath ./data/db --logpath ./data/mongod.log --port 27017 --logappend --fork --setParameter enableTestCommands=1
Se você encontrar erros "Too many open files" ao executar os testes, será necessário aumentar o número de descritores de arquivos disponíveis antes de iniciar o mongod, conforme descrito em https://www.mongodb.com/docs/manual/reference/ulimit /
Algumas etapas de configuração manual são necessárias para executar o código no IntelliJ:
Java 17+ é necessário para construir e compilar o código-fonte.
Erro: java: cannot find symbol: class SNIHostName location: package javax.net.ssl
Correção: Configurações/Preferências > Construção, Execução, Implantação > Compilador > Compilador Java - desmarque "Usar a opção '--release' para compilação cruzada (Java 9 e posterior)"
Erro: java: package com.mongodb.internal.build does not exist
Correções: Qualquer um dos seguintes:
generateBuildConfig : por exemplo: ./gradlew generateBuildConfig ou via Gradle > driver-core > Tasks > buildconfig > generateBuildConfiggenerateBuildConfig para executar antes da construção. via Gradle > Tarefas > buildconfig > clique com o botão direito generateBuildConfig - clique em "Execute Before Build"
