feat: allow unchecked SQL operators #3698
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What this PR changes/adds
This PR adds an overloaded constructor for the
SqlQueryStatement
class that allowsto disable the operator checking.
That means, that the
SqlQueryStatement
won't throw anIllegalArgumentException
anymore when it encountersa supposedly illegal operator.
Why it does that
Postgres has some very specific operators, such as the
?
, which can be used for JSONB (not JSON!) types. The?
can be used to comfortably check if a value occurs in a JSON array:Check out this stackoverflow article for another example.
Now, since we do strict checks on
=
,in
,like
, constructing such a query would not be possible.Further notes
It would have been possible to simply at the
?
operator to theSqlConditionExpression.SUPPORTED_PREPARED_STATEMENT_OPERATORS
list, but then we're dragging Postgres-specific operators into the otherwise genericSqlQueryExpression
and that felt wrong.Although I haven't verified this, there could be other operators. Typically, if the usage of those operators is needed, we're dealing with a very niche use case, where operator validation can likely be foregone.
In passing, I added a branch in the the criterion converter to account for enum ordinals, not just literals. That appears to have been a bug.
Added an overloaded constructor for the
ReflectionBasedQueryResolver
to customize the criterion-to-predicate conversionLinked Issue(s)
Needed for eclipse-edc/IdentityHub#188
Please be sure to take a look at the contributing guidelines and our etiquette for pull requests.