Repository navigation
Keep container running for as long as JVM is running #359
Description
I would like to use JDBC test container as a development database, but unfortunately JDBC container shuts down as soon as all connections are closed (
I would like to propose an option which could be specified in JDBC connection string to prevent container from stopping. It could be named TC_DAEMON and here's how I would like to use it:
jdbc:tc:postgresql://localhost?TC_DAEMON=true
Let me know what you think. I could work on a PR to implement it.
Activity
zimmi commentedon Jun 5, 2017
I'm using docker compose to start up my development database and dummy smtp server. With a single command you can start it up and also blow away any data and start from scratch. That approach works quite well for me, I can share my compose file if you want. Is there a specific reason you want to add this functionality to testcontainers? I feel it's best to keep this project focused on testing only.
inikolaev commentedon Jun 5, 2017
I like test containers approach because I can simply have a JDBC url in my configuration file and run application without thinking whether I need to run Docker Compose or not - I simply run main class from IDE and that's all.
kiview commentedon Jun 5, 2017
I'm personally not that much convinced by this idea, since it would really push the concepts behind TestContainers. Still I understand your use case. I would as well suggest to use docker-compose instead, since having a database as a dependency is still only a single use case and most projects might need multiple external dependencies (like @zimmi mentioned with the SMTP server).
inikolaev commentedon Jun 5, 2017
Well I think it might also be useful for tests. We recently migrated from H2 to TestContainers, but test speed degraded considerably (by a factor of 6-8) since it was starting a new container per test which in our case is not required. Instead we start Postgres container separately from tests and clean database before each test instead.
With this url parameter we could just configure JDBC connection string and call it a day, since TestContainers maintains a mapping
url => containerso as long as we use the same JDBC connection string across all test we would reuse existing container.Or maybe there's a better way?
kiview commentedon Jun 5, 2017
If you are using the TestContainers classes you should be able to use the
@ClassRuleannotation, so it will only started/stopped on test-class basis. If you are using the Spock version, you can use@Sharedannotation. You can also build a construct where you use an abstract base class for your database tests and start the TestContainers instance manually on initialization of the class I think.TestContainers being slower than an H2 database is in general an expected behavior, one sacrifices speed for better confidence and compatibility.
But maybe you are right and having an additional URL parameter for specifying this behavior when using the tc driver might be an useful addition, I might imagine quite a lot of people liking something like this.
We were discussing refactoring the code for extract the query parameters in #357, so it might be best to wait for this PR to be merged before starting the work in this issue.
inikolaev commentedon Jun 5, 2017
I've been experimenting with
@ClassRulebut in our case we had more test cases with one or two tests, so it didn't give much win.I have already experimented with possible fix but I'll keep an eye on the query parameters refactoring.
asafm commentedon Jun 7, 2017
inikolaev commentedon Jun 7, 2017
While parameter parsing is not resolved I have created a PR #360 so that you could take a look at the implementation.