testcontainers / testcontainers/testcontainers-java

Feature: Allow setting environment variables when using JDBC Support for Databases

Open
#5,028 8 comments 2 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

type/enhancement
Dominant language
Java
Stars
8.7k
Forks
1.9k
Avg merge
2d 17h
Merged PRs (30d)
9

Description

Hi everyone,
first of all thank you for a great library and a great documentation. I would like to suggest a feature which I would also contribute too.
But before jumping into the work I would like to discuss the idea.
When using the JDBC schema to enable a databse either during test or during the applications runtime it is currently impossible to use environment variables without programmatically starting the container (#3929). I would like to add this feature and have three possible solutions in mind.

Env Variables as Query Parameters

This idea basically would allow to set any enviroment vraiables via the url e.g. ?MSSQL_COLLATION=UTF-8. The pros are that it does not require an additional place to maintain variables from a users perspective. On the other hand imnplementation wise, it would be hard to differntiate between connections params and enviroment vraiables, which would lead to a need for another prefic like use for the initscript e.g. ENV_. Additionally the user had to url escape possibly complex strings, which would hurt readability and make for long obscure URLs.

Dedicated Properties File with specific name

As used for MSSQL container as an example it is a viable pattern to use a dedicted text file in the resources folder to enable specific settings. This proposed solution would follow the approach set in configuration for coonfiguration on the class path. This would allow for example to search for environemt variables in tc_environment.properties. While I like this approach more than the query parameters I would see it as a drawback that if I use multiple database all Enviroment variables have to be in one file. One could attempt to define a single specific filename per Image, but this would require a bigger implementation effort per module, without a significant benefit ion cases where there are two containers of the same image.

Dedicated Properties file specified via URL parameter

Thius approach is by far my favourite. This would allow to specify a prperties file via an URL Paramter as currently possible for an init script. The specifc property could be TC_ENVFILE and would allow the same options as TC_INITSCRIPT meaning either a classpath file or a file loaded from the file:: protocl from the current working directory. Analog we could offer a TC_ENVFUNCTION query parameter which would take the path to a function, which should return a Properties object.

Either way I am looking forward to your feedback and would also implement the feature if I can get your confirmation, that is a good proposal.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reviewing the JDBC support documentation, especially the init-script URL parameter and the configuration approach referenced in the issue. Compare the three proposed environment-variable mechanisms and confirm the intended URL and properties-file behavior with maintainers; done means one agreed design is documented and implementable for JDBC database containers.

Written by the indexing model from the issue text.

Assessment

Tech stack
docker, java
Domain
databases, testing
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
28/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.