-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
Allow to start daemon database container #360
Conversation
@@ -199,7 +203,7 @@ private Connection wrapConnection(final Connection connection, final JdbcDatabas | |||
|
|||
return new ConnectionWrapper(connection, () -> { | |||
finalConnections.remove(connection); | |||
if (finalConnections.isEmpty()) { | |||
if (!isDaemon && finalConnections.isEmpty()) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't you avoid starting and reuse the existing container if it exists?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This line only prevents running container from stopping if TC_DAEMON=true
was specified in connection string.
ContainerDatabaseDriver
maintains a mapping jdbcUrlContainerCache
which maps JDBC connection string to the container instance. New container won't start If such a mapping exists.
My change basically ensures that this mapping is not removed once all connections are closed.
Do you think you can provide a test for this feature as well? |
I tried making a test in jdbc module but it turned out it doesn't actually start container and there's no access to container instance, unless I pass it into I can try to use Mockito and I guess I need to register some mock |
Added test, please have a look |
@@ -70,6 +77,7 @@ public static void testCleanup() { | |||
@Test | |||
public void test() throws SQLException { | |||
performSimpleTest(jdbcUrl); | |||
performContainerStatusCheck(jdbcUrl); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since we test just a single case of TC_DAEMON here, maybe it worth to create a separate test, without Parameterized runner?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought about that, but at the same time now it tests that container is stopped for other tests without TC_DAEMON set.
Can do either way, don't have a strong opinion on it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would go with a separate test where you test both scenarios (with and without TC_DAEMON), just to make it clear if it's broken or not. IMO Parameterized runner seems to be misused in general in JDBCDriverTest :)
Thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok! One more thing, I see I'm getting a PMD violation about using package private method: ContainerDatabaseDriver.getContainer()
.
Would it be fine to make it public
? I saw some classes use VisibleForTesting
annotation, but I'm not sure if it makes any difference.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, VisibleForTesting should be used here
55f7ff6
to
d95abae
Compare
@@ -84,6 +88,27 @@ public void test() throws SQLException { | |||
} | |||
} | |||
|
|||
@Test | |||
public void shouldStopContainerWhenAllConnectionsClosed() throws SQLException { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
please move these two tests to a separate Test class, otherwise, they will execute for every parameterized data entry
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ouch, didn't realize that :)
f429d07
to
fdf33ed
Compare
Looks good to me. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me - only very minor suggestions, and a good contribution.
Thanks also for updating the docs!
Please could you also update the CHANGELOG file? I apologise that you're the first person I'm asking to do this, but we're trying to automate the release process a bit more and having changelog updates done in advance would probably be a good idea.
Please could you add something like this near the top of the changelog?
## UNRELEASED
### Changed
- Added `TC_DAEMON` JDBC URL flag to prevent `ContainerDatabaseDriver` from shutting down containers at the time all connections are closed.
/** | ||
* Created by inikolaev on 08/06/2017. | ||
*/ | ||
public class DatabaseDriverTest { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please could you rename to be slightly more specific? i.e., this could be called DatabaseDriverShutdownTest
or something like that.
* @return an instance of database container or <code>null</code> if no container associated with JDBC URL | ||
*/ | ||
@VisibleForTesting | ||
public static JdbcDatabaseContainer getContainer(String jdbcUrl) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If this is only for use in testing, couldn't we make it package-scoped? That way it doesn't become part of the public API.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It was package-private first, but that causes PMD violation when Codacy runs different checks. Any ideas on how to fix that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would ignore the Codacy check and use package-scope.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a way to adjust PMD rules? Else a more serious issue might be missed due to the noise this issue will add to every build.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are lot's of places in the existing codebase, where we're violating this rule. Since it's not a really useful rule if you want to use package-scope, I'd say we simply deactivate this pattern in Codacy. @rnorth are you okay with this?
fdf33ed
to
c07e31d
Compare
Could someone trigger Travis build - seems like it was terminated for some reason, but is passes locally. |
@inikolaev have restarted the build, sorry. Not quite sure why it hung there.. |
Green now :) |
Merged, thank you @inikolaev ! |
Awesome! 😄 |
This PR fixes #359 by supporting new boolean option
TC_DAEMON
which prevents container from stopping when all connections are closed.