DB2 принудительно использует BITWISE-OR, если используется ResultSet.TYPE_SCROLL_INSENSITIVE

Question

Я использую JDBC для подключения к db2 luw с ускорением blu 11.x db2 luw без ускорения blu имеет ту же проблему.

conn.createStatement(
                ResultSet.TYPE_SCROLL_INSENSITIVE,
                ResultSet.CONCUR_READ_ONLY,
                ResultSet.HOLD_CURSORS_OVER_COMMIT)
ResultSet rs = stmt.executeQuery(sql);

Возможный запрос в нашем приложении (упрощенный), где myNumericColumn представляет собой числовой тип данных:

SELECT * FROM myTable WHERE
    myNumericColumn = 123 OR 'ALL' IN (123)

123 можно изменить на другое значение. Подготовленная строка возможна как 'ALL'. В этом случае запрос выглядит так:

SELECT * FROM myTable WHERE
    myNumericColumn = 'ALL' OR 'ALL' IN ('ALL')

Правая рука будет истинной, поэтому левая рука не будет оцениваться. Если я удаляю правую руку (или меняю условие для оценки на false), мы получаем исключение числового переполнения (сравниваем числовое со строкой).

com.ibm.db2.jcc.am.SqlDataException: Overflow occurred during numeric data type conversion.. SQLCODE=-413, SQLSTATE=22003, DRIVER=4.23.42

Если я изменю createStatement на следующую команду или удаляю все атрибуты ResultSet (по умолчанию будет использоваться ResultSet.TYPE_FORWARD_ONLY), исключений не будет.

conn.createStatement(
                ResultSet.TYPE_FORWARD_ONLY,
                ResultSet.CONCUR_READ_ONLY,
                ResultSet.HOLD_CURSORS_OVER_COMMIT)

Зачем заставляет JDBC / JDBC-драйвер / базу данных использовать побитовое или если я меняю тип ResultSet? Как можно изменить это поведение?

Спасибо и всего наилучшего

Answer 1

Ответ прост: не делайте таких вещей .
В предикатах есть оператор описание:

• Все указанные значенияв предикате должен быть совместим

Нет никакой гарантии, если предикат условия поиска действительно оценен и в каком порядке в каком-то конкретном случае.