JdbcDatabaseContainer doesn't have lazy image constructor

[npetzall]

Hi

Is there a reason why JdbcDatabaseContainer doesn't have the super constructor with Future image)?

public JdbcDatabaseContainer(@NonNull final Future<String> image) {
        super(image);
}

[iNikem]

What is the use-case that requires this type of construction??

[npetzall]

I want to be able to access the instance method getJdbcDriverInstance() before the images has been pulled.

I have written a junit wrapper library and the assumeDriver function is too slow. Since I use custom JDBC containers that requires proprietary drivers they might not be available and I want that to be checked before pulling the image.

Library exists more or less to add assumptions.

With the lazy loading I can skip the image pull if the driver is missing by skipping the test before it actually pulls/starts the container.

[iNikem]

wow, I think the correct question is "why public GenericContainer(String dockerImageName) pulls the image?" :)

[bsideup]

@iNikem yes, @rnorth, why? :D Jokes aside, AFAIR Richard wanted tests to fail fast if image pull fails.
We briefly discussed that when I was working on #106

[rnorth]

Precisely that, to fail fast. If a test class declares multiple @Rules, it seem(s/ed?) bad to spend time starting some of them, but then fail to pull a non-existent image.

This was an old decision though - happy to revisit in light of how people want to use the tool nowadays, and whether this makes sense.

[npetzall]

So adding the suppressed constructor wouldn't be a problem.

Other if possible solution would be to query repositories to see if image exists but to do pulling in start/tryStart.

DockerClient has a search cmd.