-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
Trim string values defined in the Hibernate ORM configuration #22816
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1 to merge this, but... why in the world is trimming not the default?
I suppose it's something related to the Microprofile spec, or an ongoing battle with someone else arguing we should do no such thing?
I cannot think of any property (at least in Hibernate ORM/Search) where we would assign meaning to a leading/trailing space. And even if there was one, it would be much safer to add an exception for that property than to manually use TrimmedStringConverter
on every single property except the one that should not be trimmed...
Hibernate Search, internally, certainly does trim everything before processing any configuration property, but any processing in the Hibernate Search (e.g. processing a bean reference extracted from the configuration properties) is at risk too. So I guess I'll have to do the same as you for the Hibernate Search extension... ?
core/runtime/src/main/java/io/quarkus/runtime/configuration/CharsetConverter.java
Show resolved
Hide resolved
After discussion with Roberto and per the MP Config spec, TrimmedStringConverter should return null if the string is empty. It fixes the semantic and allows to use with Optional<String>.
That would be a question for @radcortez . I must admit that I agree with you. We had a discussion about this back in the days with David and in the end the initial behavior was kept. IIRC the main argument for it was to respect how .properties work and their trimming rules. I could see how you would want to not trim user-defined properties though (think email subject prefix for instance). But I agree that would be marginal. That being said, I'm not sure that's something we can break now. |
31c0807
to
bfabc1c
Compare
No :)
Exactly. Maybe what we can do is trim properties in the |
That would be awesome. We can always override the converter if we don't need trimming for one exotic property. |
Exactly. @gsmet do you remember any config on our side where we may want to conserve the original value? |
That's a good question, thanks for asking... :). I think the only way to really know that would be to do a quick scan of all the configuration properties in the configuration reference page. But I can't do that anymore with my bad eyes :/. I'm not sure having a different behavior for a specific namespace is a good idea, though. In any case:
|
Sure. I was not proposing to do it here. I'll open a separate issue so we don't forget. |
Failing Jobs - Building bfabc1c
Full information is available in the Build summary check run. Failures⚙️ Gradle Tests - JDK 11 Windows #- Failing: integration-tests/gradle
📦 integration-tests/gradle✖
|
Fixes #20492