Как определить, поддерживает ли драйвер JDBC PreparedStatement?

#jdbc #prepared-statement

#jdbc #подготовленное заявление

Вопрос:

Есть ли способ программно определить, поддерживает ли конкретный драйвер JDBC PreparedStatement без вызова ExecuteQuery() и обнаружения исключения «не реализовано»?

Комментарии:

1. Подождите. Есть ли какой-либо драйвер, не поддерживающий подготовленные операторы? Это был бы совершенно непригодный драйвер.

2. Вызовите Connection.prepareStatement() и посмотрите, что произойдет. Если вы получили PreparedStatement , это работает. Если нет, то нет. Вы даже не можете дойти до того, чтобы попробовать то, что вы предложили. Но я согласен с @JBNizet, что это не проблема.

3. Вы не поверите, сколько существует недоделанных драйверов. Спасибо за вашу идею использовать try-catch сразу после подключения. prepareStatement(). Большинство «полуфабрикатов» драйверов, таких как Hive ( central.maven.org/maven2/org/apache/hive/hive-jdbc/3.1.0 / … ) на самом деле использует это утверждение, так что к черту все остальное.

Ответ №1:

Любой совместимый драйвер JDBC должен реализовывать подготовленную инструкцию. Если у вас есть драйвер, который не поддерживает подготовленные операторы, он формально не является драйвером JDBC (даже если он реализует (часть) API JDBC).

Поскольку спецификация JDBC требует поддержки подготовленных операторов, в API нет ничего, чтобы проверить, поддерживаются ли они. Свяжитесь с поставщиком / автором этого драйвера и скажите им, что подготовленные заявления не являются необязательными. К сожалению, это означает, что вы не сможете обнаружить ее до выполнения.

Кроме того, я был бы весьма удивлен, если бы какой-либо драйвер, не поддерживающий подготовленные инструкции, позволил бы подготавливать инструкции, но только сбой во время выполнения. Для меня это означало бы, что подготовленные операторы поддерживаются (иначе почему бы просто не завершиться ошибкой при Connection.prepareStatement вызове), но что бы вы ни делали, это не поддерживается (например, вызов executeQuery(String) вместо executeQuery() ).

Комментарии:

1. Он не «ссылался» на какой-либо «неназванный драйвер», который «разрешает подготовку операторов, но завершается сбоем только во время выполнения». Вы это придумали.

2. @user207421 Верно, я предполагаю, что здесь OP сталкивается с проблемой, когда подготовленное утверждение executeQuery выдает «не реализовано» и ищет общий способ его обнаружения и предотвращения. Без этого предположения я не совсем понимаю, зачем вообще нужно задавать этот вопрос.

3. Я не вижу никаких оснований для такого предположения. Мне кажется, что он просто догадывается. Это, по крайней мере, столь же вероятно, как и ваше предположение.

4. @user207421 Справедливо, я немного перефразировал это.