Skip to content
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

Feature/urlparser improve3 pr1 #2641

Merged
merged 6 commits into from Oct 17, 2022

Conversation

MarekUniq
Copy link
Contributor

All Submissions:

  • Have you followed the guidelines in our Contributing document?
  • Have you checked to ensure there aren't other open Pull Requests for the same update/change?

comment from PR #2569 by @davecramer
can you break this up into multiple PR's ? As it is it is a bit too big to properly review.

This PR is replacement for PR #2569
This is first PR. This PR does not change any functionality.

@MarekUniq MarekUniq mentioned this pull request Oct 15, 2022
8 tasks
@davecramer
Copy link
Member

There are a few places where you are changing logLevel to loggerLevel, but we removed loggerLevel in 09c2c37

@MarekUniq
Copy link
Contributor Author

@davecramer

... logLevel to loggerLevel

There is property LOGGER_LEVEL in PGProperty.java file:

LOGGER_LEVEL(
"loggerLevel",
null,
"Logger level of the driver",
false,
new String[] {"OFF", "DEBUG", "TRACE"}),

Property "logLevel" does not exist.

While converting free-text string to enum property, the free-text value "logLevel" conversion fails. We need to change it either to correct value "loggerLevel" or remove invalid value at all.

If LOGGER_LEVEL property is deprecated then it should be annotated accordingly?

I have limited information about the development history. I can fix the faulty property. I have no basis for deciding that a correct property is wrong. This is where your specific input is required.

@davecramer
Copy link
Member

Well you can see the comment right above the line that you referenced which says it's not used.
At this point I'm ambivalent. You could choose to remove it or I can merge this PR the way it is and I will remove it later.

@MarekUniq
Copy link
Contributor Author

@davecramer I removed usage of/references to "logLevel" and "loggerLevel". Is it better now?

@davecramer
Copy link
Member

Yes, it's fine. I had to restart some checks. I will get around to merging it soon.

@davecramer davecramer merged commit ee06e22 into pgjdbc:master Oct 17, 2022
Copy link
Member

@vlsi vlsi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe we should back out the changes since it introduces an unexpected change in behavior

Comment on lines -858 to +871
public @Nullable String get(Properties properties) {
public @Nullable String getOrDefault(Properties properties) {
return properties.getProperty(name, defaultValue);
}

/**
* Returns the value of the connection parameters according to the given {@code Properties}
*
* @param properties properties to take actual value from
* @return evaluated value for this connection parameter or null
*/
public @Nullable String get(Properties properties) {
return properties.getProperty(name);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks like a severe breakage of the public API.
Previously .get did take the default value into the consideration, while now get ignores the default value.

I believe code like PGProperty.PG_HOST.get(properties) is used in the wild, and it looks like it would change the behavior after this change.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will revert it. Thanks!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alternatively we could just fix PGProperty.PG_HOST.get(properties) so that it worked as before ? Do you have any issues with the rest of the PR ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, I should have figured it out myself that get() could be used by external libraries.

Can I make rollback commit to the same PR here and it can be merged again? (or new PR is required)

What could be the name of another method:

  • getWithoutDefault()
  • getNoDefault()
  • ?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if the only issue with this PR is that get should be reverted we can just fix that as per PR # 2644
After contemplating this a bit, I'm not sure of the value of using getOrDefault ?
@vlsi do you have any other issues with the PR ?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, we can probably keep getOrDefault so it explicitly conveys the behavior.

We can keep get() which would delegate to getOrDefault, and mark it as @Deprecated (without intention to remove the method), so the clients who use the methods could either migrate to the "new" getOrDefault or getWithoutDefault, etc.

I think getOrNull(...) would be better alternative than getWithoutDefault and getIgnoringDefault.
AFAIK, Properties (and Hashtable) does not support null values, and orNull in the method name gives an explicit warning that the method can return null.

I don't like getNoDefault.
Yet another alternative could be getIgnoringDefault, however, I think getOrNull is better for "get value or return null if it is missing in the properties".

Copy link
Contributor Author

@MarekUniq MarekUniq Oct 19, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@davecramer

if the only issue with this PR is that get should be reverted we can just fix that as per PR #2644

yes, that's good

@vlsi

I think getOrNull is better ...

I like it.

davecramer added a commit that referenced this pull request Oct 17, 2022
@MarekUniq MarekUniq mentioned this pull request Oct 20, 2022
8 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants