URI parsing adds additional properties to configuration rather than properties map.
See original GitHub issueI’m working in HR #1059 and trying to leverage the DB-specific SqlConnectOptions parsing of a URL string to allow additional properties on the URL but it looks like the parse logic isn’t capturing these properties except for a few in the PgConnectionUriParser.
The expectation would be that additional properties would be returned with a call to SqlConnectOptions.getProperties()
By using this URL String url = "jdbc:postgresql://testuser:testpassword@localhost:11111/hreact?prop1=value1&prop2=value2";
and calling PgConnectOptions.fromUri(…) prop1 and prop2 are dropped because any extra parsed props are put
into the configuration rather than the properties.put
I’ve changed configuration.put(key, value);
to properties.put(key, value);
locally and the properties are added to the options however, because the SqlConnectOptions
properties are stored in a HashMap() and the conversion to JSON may end up failing in the fail assertEquals(expectedConfiguration, actualConfiguration);
because the properties aren’t necessarily ordered in a HashMap().
The following test added to PgConnectOptionsTest
should work, but it fails.
@Test
public void testValidUriShouldSucceed() {
connectionUri = "postgresql://?fallback_application_name=myapp&search_path=myschema&prop1=value1&prop2=value2&prop3=value3&loggerLevel=OFF";
actualConfiguration = PgConnectOptions.fromUri(connectionUri);
Map<String, String> expectedProperties = new HashMap<>();
expectedProperties.put("fallback_application_name", "myapp");
expectedProperties.put("search_path", "myschema");
expectedProperties.put("prop1", "value1");
expectedProperties.put("prop2", "value2");
expectedProperties.put("prop3", "value3");
expectedProperties.put("loggerLevel", "OFF");
expectedConfiguration = new PgConnectOptions()
.setProperties(expectedProperties);
assertEquals(expectedConfiguration, actualConfiguration);
}
Is there a reason why the assertEquals() check compares the JSON string only? I would think that the order of general JSON property elements shouldn’t matter.
Maybe the assertEquals() could be modified to do a more specific check for equality and in particular specific additional properties?
Issue Analytics
- State:
- Created 2 years ago
- Comments:23 (16 by maintainers)
@gavinking I don’t disagree with you, I’m saying that some documented parameters are for the client and either the pg client supports them or it does not. So we need for the client side parameters to log at least that it will not work as expected.
I will try to support more of them like TCP time out, etc… some seem not hard to implement.