-
Notifications
You must be signed in to change notification settings - Fork 4
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
Enum fixes #70
Enum fixes #70
Conversation
@@ -512,6 +513,19 @@ String getValuesForSignature() { | |||
|
|||
abstract List<?> getSortedMembers(); | |||
|
|||
protected <T> String createInCondition(String metadataTableName, String columnName, List<T> membersList) { |
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.
Is there any possibility that the strategy of multiple IN large in clauses will blow up the query planner?
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.
At least currently, this is an edge case (fungi has 1118 strains) so splitting one in clause into two is probably ok. We could potentially see long running jobs in the future if for some reason we have many thousands of options in a membership filter, but we should be able to see that in the SQL and can address if it happens. For now it is fine.
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.
i added a comment which is likely a non-issue, but worth touching on
This PR addresses two separate issues (combined only for testing convenience):
The issue at the bottom of https://redmine.apidb.org/issues/12938, namely for the
refreshed-dependent-params
endpoint to throw 422 instead of 500 in the following instance:a. Param A is a multi-pick enum param requiring >0 selected terms in a runnable context (but not displayable context)
b. Param B is a filter param (enum would also have this problem) which depends on A and whose vocabulary queries cannot support an empty value (no selected terms) for Param A
c. User clicks "Select None" in Param A, triggering a call to
refreshed-dependent-params
to get the new vocabulary and default value for Param BThe issue described in https://redmine.apidb.org/issues/51649, namely that membership filters in filter params cannot handle >1000 terms (SQL breaks Oracle's 1000 term limit in
in
clauses).