The resolution to this is that we are simply going to warn users via logging when this condition is detected. We feel this is simply a bad application design to be doing such large IN element restrictions, not to mention that there is no viable fix that works in all cases.
And its not just an issue with "customiz[ing] the IN clause generated / prepared statement binding". That is in fact the least of the problems. The bigger issues are with splitting the queries and then hashing results back together. Especially when conjunctions/disjunctions (ANDs/ORs) complicate the problem.
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
The resolution to this is that we are simply going to warn users via logging when this condition is detected. We feel this is simply a bad application design to be doing such large IN element restrictions, not to mention that there is no viable fix that works in all cases.
And its not just an issue with "customiz[ing] the IN clause generated / prepared statement binding". That is in fact the least of the problems. The bigger issues are with splitting the queries and then hashing results back together. Especially when conjunctions/disjunctions (ANDs/ORs) complicate the problem.
We will revisit this once the work identified as https://hibernate.onjira.com/browse/HHH/fixforversion/10690 is underway. See HHH-7572