-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Add configuration option to disable usage of JSqlParser for native queries. #3623
Conversation
…eries. This commit introduces the spring.data.jpa.query.native.parser property that allows to switch native query parsing to the default internal parser for scenarios where JSqlParser is on the classpath but should not be used by spring-data.
I do not consider the |
if (!StringUtils.hasText(name)) { | ||
return AUTO; | ||
} | ||
return NativeQueryEnhancer.valueOf(name.toUpperCase()); |
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.
How about ObjectUtils.caseInsensitiveValueOf(…)
?
*/ | ||
static NativeQueryEnhancer select(ClassLoader classLoader) { | ||
|
||
if (!ClassUtils.isPresent("net.sf.jsqlparser.parser.JSqlParser", classLoader)) { |
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.
For Graal Native, wouldn't we want to keep this check within a field?
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.
the check would still work just not be initialized at build time which is not necessary since its done only once and forgotten afterwards.
|
||
private static final boolean jSqlParserPresent = ClassUtils.isPresent("net.sf.jsqlparser.parser.JSqlParser", | ||
QueryEnhancerFactory.class.getClassLoader()); | ||
private static final NativeQueryEnhancer NATIVE_QUERY_ENHANCER; |
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.
With SpringProperties
falling back to System Properties, wouldn't we want to keep the selection dynamic to allow changing system property values at runtime?
More with the rationale of setting the value later and not so much for flipping it.
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.
While we could do it, I'd rather have it set in stone. Allowing to change values at runtime might lead to interesting side effects in its best case, and we'd have to do the lookup every single time.
That's merged, polished, and backported now. |
This commit introduces the
spring.data.jpa.query.native.parser
property that allows to switch native query parsing to the default internal parser for scenarios whereJSqlParser
is on the classpath but should not be used by spring-data-jpa.See: #2989