feat: allow customization of data dir between database initialization and start #145
Conversation
| @@ -583,7 +595,7 @@ public EmbeddedPostgres start() throws IOException { | |||
| } | |||
| return new EmbeddedPostgres(parentDirectory, builderDataDirectory, builderCleanDataDirectory, config, | |||
| localeConfig, builderPort, connectConfig, pgBinaryResolver, errRedirector, outRedirector, | |||
| pgStartupWait, overrideWorkingDirectory); | |||
| pgStartupWait, overrideWorkingDirectory, dataDirectoryCustomizer); | |||
| } | |||
|
|
|||
| @Override | |||
There was a problem hiding this comment.
The new variable needs to be included in the equals and hashCode method implementations. Comparing lambda functions isn't easy, so in this case, I would suggest comparing the results of getClass() calls, see the example below:
Objects.equals(dataDirectoryCustomizer != null ? dataDirectoryCustomizer.getClass() : null, builder.dataDirectoryCustomizer != null ? builder.dataDirectoryCustomizer.getClass() : null)
And similar logic in the hashCode method implementation.
There was a problem hiding this comment.
Ok, I would fix this. Thanx for advice!
| @@ -47,10 +48,18 @@ public void testEmbeddedPg() throws Exception | |||
| @Test | |||
| public void testEmbeddedPgCreationWithNestedDataDirectory() throws Exception | |||
There was a problem hiding this comment.
This test feels a little bit contrived. Instead of this approach, it would be better to actually modify a configuration file (like postgres.conf, doesn't have to be pg_hba.conf) and then verify through SQL queries that this change is correctly applied.
Similar to this test: https://github.com/zonkyio/embedded-database-spring-test/blob/master/embedded-database-spring-test/src/test/java/io/zonky/test/db/config/ConfigurationPropertiesIntegrationTest.java
There was a problem hiding this comment.
The whole point of this test is to verify that lambda is called with the proper dir, not to test lambda logic or abilities—it can be anything useful between init and start, even modifications of template databases. So why do we need to check the distinct file modification effect, what do we verify by that?
There was a problem hiding this comment.
We verify that the entire concept works. The purpose of this pull request is to enable changes to the Postgres process configuration, not just to ensure that the lambda function is called with the correct parameters.
If you make the change below, the test will still pass, but the customizer will have no effect. This means that the test is insufficient. That’s my point.
lock();
// if (dataDirectoryCustomizer != null) {
// dataDirectoryCustomizer.accept(dataDirectory);
// }
startPostmaster();
if (dataDirectoryCustomizer != null) {
dataDirectoryCustomizer.accept(dataDirectory);
}
I doubt I chose the right name...but it works
Refs: #144