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

feat/chainable translators #542

Merged
merged 7 commits into from
Mar 7, 2024
Merged

Conversation

michael-simons
Copy link
Collaborator

  • chore: Use correct version numbers in all @since tags.
  • build: Don’t generate JavaDoc for benchkit and doc modules.
  • build: Use Mockito bom.
  • build: Add semantic versioning checks to verification.
  • feat: Add support for chaining SQL translators.

@michael-simons michael-simons self-assigned this Mar 5, 2024
meistermeier
meistermeier previously approved these changes Mar 6, 2024
Copy link
Contributor

@meistermeier meistermeier left a comment

Choose a reason for hiding this comment

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

I trust you on the Maven config bits here, because I am not this familiar with this (foremost japicmp).
Some remarks in the comments.


@Override
public String apply(String sql) {
if (this.translators.size() == 1) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Regarding readability / maintenance:
Is this special handling for size == 1 really needed?
Yes, the iterator is not invoked here and it might have performance benefits but shouldn't take the JVM care of optimising this?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Burned by this too many times wrt streams.

}

private int getOrder(SqlTranslator sqlTranslator) {
if (sqlTranslator != null) {
Copy link
Contributor

Choose a reason for hiding this comment

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

At this point the SqlTranslator should never be null.
Maybe a check in the public compare method for this with potential exception throwing. I mean even Java built-in types have no nice mitigation for null values on compare.
What might be checked for null is the value of SqlTranslator#getOrder because it can be overwritten to return null.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

It can't return null, only 0, it's an int.

Copy link
Contributor

Choose a reason for hiding this comment

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

🤦 myself..nothing to see here 😄

The former is provided for two reasons: It allows us to distribute the driver with and without the bundled, default translator and can be an option for you to run your custom translator.

Translators can be chained, and you can have as many translators on the class-path as you want.
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
Translators can be chained, and you can have as many translators on the class-path as you want.
Translators can be chained, and you can have as many translators on the class path as you want.

Also note that there is as well classpath in the current documentation. This should get unified.

Copy link
Collaborator Author

@michael-simons michael-simons Mar 6, 2024

Choose a reason for hiding this comment

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

Most official docs use classpath (Edit: Geez autocorrect)

Copy link
Contributor

Choose a reason for hiding this comment

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

Then my suggestion is of course

Suggested change
Translators can be chained, and you can have as many translators on the class-path as you want.
Translators can be chained, and you can have as many translators on the classpath as you want.

😺

@michael-simons michael-simons force-pushed the feat/chainable-translators branch 2 times, most recently from 1877401 to 445797e Compare March 6, 2024 18:31
meistermeier
meistermeier previously approved these changes Mar 7, 2024
michael-simons and others added 2 commits March 7, 2024 10:45
SQL translators now can be ordered and you can have as many SQL translator factories as you want on the class- or module-path. The will be called in order of highest precedence, and individual translators but the last are free to fail or to modify the intermediate statement.

No additional translators are provided in this commit.

Co-authored-by: Gerrit Meier <[email protected]>
@michael-simons michael-simons merged commit 6caa1e6 into main Mar 7, 2024
8 checks passed
@michael-simons michael-simons deleted the feat/chainable-translators branch March 7, 2024 10:05
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.

2 participants