feat: allow customization of data dir between database initialization and start#145
Conversation
| 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!
| } | ||
|
|
||
| @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);
}There was a problem hiding this comment.
Perfect, thanks! This change will help solve/work around a lot of existing configuration issues, so I'm very grateful for this pull request 👍
|
Hi @vladimirfx, are you planning to finish this pull request? All you need to do is rework the test. |
2 participants
I doubt I chose the right name...but it works
Refs: #144