Add Db2 module #1237
Add Db2 module #1237
Conversation
✅ Deploy Preview for testcontainers-dotnet ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
✅ Deploy Preview for testcontainers-dotnet ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
…d of generating the whole file
…ng merge conflict resolution
…et into kevin0x90-Db2Support
| .WithDatabase(DefaultDatabase) | ||
| .WithUsername(DefaultUsername) | ||
| .WithPassword(DefaultPassword) | ||
| .WithLicenseAgreement() |
| /// <summary> | ||
| /// Sets the Db2 archive logs. | ||
| /// </summary> | ||
| /// <param name="archiveLogs">The Db2 archive logs setting.</param> | ||
| /// <returns>A configured instance of <see cref="Db2Builder" />.</returns> | ||
| public Db2Builder WithArchiveLogs(bool archiveLogs) | ||
| { | ||
| return Merge(DockerResourceConfiguration, new Db2Configuration(archiveLogs: archiveLogs)) | ||
| .WithEnvironment("ARCHIVE_LOGS", archiveLogs.ToString()); | ||
| } | ||
|
|
||
| /// <summary> | ||
| /// Sets the Db2 autoconfig setting. | ||
| /// </summary> | ||
| /// <param name="autoConfig">The Db2 autoconfig setting.</param> | ||
| /// <returns>A configured instance of <see cref="Db2Builder" />.</returns> | ||
| public Db2Builder WithAutoconfig(bool autoConfig) | ||
| { | ||
| return Merge(DockerResourceConfiguration, new Db2Configuration(autoConfig: autoConfig)) | ||
| .WithEnvironment("AUTOCONFIG", autoConfig.ToString()); | ||
| } |
There was a problem hiding this comment.
Do we need to provide an API for these configurations? Usually, modules only include what's necessary to run the container; we do not provide an API for every single configuration. Developers can always configure the environment variables themselves (if they are optional).
There was a problem hiding this comment.
I thought it makes these settings more discoverable for users.
There was a problem hiding this comment.
From our experience providing APIs (except when necessary to start the container), for configurations that can simply be set through environment variables have several disadvantages:
- Depending on the number of configurations, providing APIs for all of them requires significant effort.
- Distinguishing between different image versions and their respective configurations is difficult.
- We need to include and maintain documentation.
- Keeping the APIs and documentations up to date.
Testcontainers' modules are opinionated, pre-configured, and follow best practice configurations. A module does not need to support all possible use cases. If developers require a specific configuration, they can always use the generic builder (ContainerBuilder()).
If certain configurations are useful for development and testing, we should set them by default, as we do for PostgreSQL. If the APIs are not necessary, I recommend removing them.
| /// <returns>A configured instance of <see cref="Db2Builder" />.</returns> | ||
| public Db2Builder WithInMemoryDatabase() | ||
| { | ||
| return Merge(DockerResourceConfiguration, new Db2Configuration(licenseAgreement: DefaultInMemoryDatabasePath)) |
There was a problem hiding this comment.
This line passes the value to the wrong argument.
| /// <summary> | ||
| /// Gets the Db2 database. | ||
| /// </summary> | ||
| public string Database { get; } | ||
|
|
||
| /// <summary> | ||
| /// Gets the Db2 username. | ||
| /// </summary> | ||
| public string Username { get; } | ||
|
|
||
| /// <summary> | ||
| /// Gets the Db2 password. | ||
| /// </summary> | ||
| public string Password { get; } | ||
|
|
||
| /// <summary> | ||
| /// Toggle for archivation of logs. | ||
| /// </summary> | ||
| public bool ArchiveLogs { get; } | ||
|
|
||
| /// <summary> | ||
| /// Toggle for database autoconfiguration. | ||
| /// </summary> | ||
| public bool AutoConfig { get; } | ||
|
|
||
| /// <summary> | ||
| /// License agreement value. | ||
| /// </summary> | ||
| public string LicenseAgreement { get; } | ||
|
|
||
| /// <summary> | ||
| /// Path to the database files that should be mapped into memory (tmpfs). | ||
| /// </summary> | ||
| public string InMemoryDatabasePath { get; } |
There was a problem hiding this comment.
We only include the properties in the configuration type that we will need later in the container type.
| [PublicAPI] | ||
| public sealed class Db2Builder : ContainerBuilder<Db2Builder, Db2Container, Db2Configuration> | ||
| { | ||
| public const string Db2Image = "icr.io/db2_community/db2:latest"; |
There was a problem hiding this comment.
Please pin the version.
| // By default, the base builder waits until the container is running. However, for Db2, a more advanced waiting strategy is necessary | ||
| // If the user does not provide a custom waiting strategy, append the default Db2 waiting strategy. | ||
| var db2Builder = DockerResourceConfiguration.WaitStrategies.Count() > 1 | ||
| ? this | ||
| : WithWaitStrategy(Wait.ForUnixContainer() | ||
| .UntilMessageIsLogged("All databases are now active") | ||
| .UntilMessageIsLogged("Setup has completed.") | ||
| .AddCustomWaitStrategy(new WaitUntil(DockerResourceConfiguration)) | ||
| ); |
There was a problem hiding this comment.
Please move the wait strategy configuration to Init(). We do not need the pattern here. We only need it if we need to configure the wait strategy with developer-provided configurations.
What does this PR do?
Adds a module to use Db2 with testcontainers.
How to test this PR
Automated tests have been added to the project that verify startup and database connectivity.