Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Possible documentation refinement for the MongoDBContainer module #697

Open
csprocket777 opened this issue Dec 20, 2023 · 7 comments
Open
Labels
documentation Changes to documentation

Comments

@csprocket777
Copy link

Expected Behaviour
I was following the instructions on the MongoDB Module page and trying to implement in an ES6 environment that outputs CommonJS. The examples don't include the require()/import statement which would have helped a ton.

I also expected that once getting the container running and returning the value from container.getConnectionString() that it would simply connect using that string. I found that I had to add ?directConnection=true to the connection string for it to actually connect.

Also, the checkMongo function seems to be from the test suite instead of from the library itself.

Proposed changes:

  1. Make the generic similar to the below:
  // ES6
  import { MongoDBContainer, StartedMongoDBContainer }  from '@testcontainers/mongodb';
  // --or--
  // CommonJS
  const { MongoDBContainer, StartedMongoDBContainer } = require('@testcontainers/mongodb');

  const mongodbContainer:StartedMongoDBContainer = await new MongoDBContainer().start();

  // ...your code

  await mongodbContainer.stop();
  1. It would be super helpful to have some API docs for the modules. I ended up using container.getConnectionString() to get the connection string back to my testing suite.
  2. Include a note about the usage of ?directConnection=true in conjunction with the connection string returned. I ended up concatenating it to the end elsewhere: mongodb://localhost:[PORT]/test-db?directConnection=true

Environment Information

  • Operating System: MacOS 14.2 (Apple M1 Max)
  • Docker Version: 24.0.7, build afdd53b
  • Node version: v18.12.1
  • Testcontainers version: ^10.4.0
@robvanderleek
Copy link

I bumped into the same issues.

FWIW, I've created a minimal example repository that shows the issue when not using directConnection: true: https://github.com/robvanderleek/testcontainers-mongodb-issue

Environment Information

  • Operating System: MacOS 14.3.1 (Apple M1 Max)
  • Docker Version: 24.0.6
  • Node version: v20.11.0
  • Testcontainers version: ^10.7.1

@cristianrgreco
Copy link
Collaborator

I'm no Mongo expert.. should directConnection=true be included by default in the connection string?

@robvanderleek
Copy link

Also not an expert, but I tested connecting to a natively running MongoDB (using Homebrew) and a containerized MongoDB (launched with docker run -p 27018:27017 mongo:6.0.1) and they both work without directConnection=true.

@cristianrgreco
Copy link
Collaborator

I've noticed the Java implementation of Testcontainers does not expose this directConnection option either. IMO it's a decision for whoever is setting up Mongo/the library they use to connect to decide whether or not to use this option.

@talgendler
Copy link

@cristianrgreco Hi, by default the code creates a Mongodb Replica Set

class MongoDBContainer extends testcontainers_1.GenericContainer {
    constructor(image = "mongo:4.0.1") {
        super(image);
        this.withExposedPorts(MONGODB_PORT)
            .withCommand(["--replSet", "rs0"])
            .withWaitStrategy(testcontainers_1.Wait.forLogMessage(/.*waiting for connections.*/i))
            .withStartupTimeout(120000);
    }
....

Hence you need to tell the driver to use a direct connection.
If you tested this container with mongosh from a command line you can see that it adds this option by default.

$ mongosh localhost:55076/somedb

Current Mongosh Log ID:	65d36046a01ccf3f8e133100
Connecting to:		mongodb://localhost:55076/somedb?directConnection=true&serverSelectionTimeoutMS=2000&appName=mongosh+2.1.4

@kelchm
Copy link

kelchm commented Mar 14, 2024

This tripped me up as well, as I wasn't expecting Testcontainers to create a replica set by default.

I agree that at minimum the docs need to be updated to make this clear and ideally the implementation would support both use cases.

@cristianrgreco
Copy link
Collaborator

cristianrgreco commented Mar 14, 2024

Thanks all for the feedback. If the docs made it clear that by default the container starts a replica set, and update the connection URI to work appropriately, would you still feel the need to support both use cases? Any PR to address either of these would be very welcome.

@cristianrgreco cristianrgreco added the maintenance Improvements that do not change functionality label Mar 17, 2024
@cristianrgreco cristianrgreco added documentation Changes to documentation and removed maintenance Improvements that do not change functionality labels Apr 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Changes to documentation
Projects
None yet
Development

No branches or pull requests

5 participants