Есть ли какой-либо недостаток использования long вместо int при подготовке оператора в java?

Question

Есть ли какой-либо недостаток использования long вместо int при подготовке оператора в java?

0

Если я использую PreparedStatement.setLong для параметра, соответствующий столбец db которого действительно является integer MySql, передача int явно увидит, что он автоматически расширится в java. Но в "нижних" уровнях jdbc это имеет какое-то значение? Хорошо ли использовать long чтобы избежать дополнительной работы, если я ожидаю, что тип данных столбца db изменится на biginteger в относительно ближайшем будущем?

EDIT: Я имею в виду, что метод, устанавливающий long всегда принимает int, поэтому я не случайно передам значение, которое слишком велико для столбца db.

EvenLisle 26 июнь 2018, в 10:56

Источник

Теги:

mysql

java

jdbc

prepared-statement

primitive

1 ответ

Ещё вопросы

Mark Rotteveel · Accepted Answer · 2018-06-26T11-49-00.000Z

Если посмотреть на 100% -ную официальную перспективу, возможно, небезопасно использовать setLong для столбца INTEGER. Спецификация JDBC 4.3 говорит о том, что setXXX -methods (за исключением setObject) следует за сопоставлениями приложения B.2, в котором говорится, что Java long отображает SQL BIGINT. Затем это зависит от того, может ли драйвер или база данных использовать значение BIGINT со столбцом INTEGER.

Спецификация JDBC 1.20 по этому вопросу гласит:

7.2.1 Соответствие типов данных по параметрам IN

Методы PreparedStatement.setXXX не выполняют никаких преобразований общего типа данных. Вместо этого значение Java просто сопоставляется с соответствующим типом SQL (после отображения, указанного в таблице 3 на стр. 28), и это значение отправляется в базу данных.

Ответственность программистов состоит в том, чтобы убедиться, что тип java каждого аргумента соответствует типу SQL, который совместим с типом данных SQL, ожидаемым базой данных. Для максимальных программистов переносимости следует использовать типы Java, которые соответствуют точным типам SQL, ожидаемым базой данных.

Если программистам требуются преобразования типа данных для параметров IN, они могут использовать метод PreparedStatement.setObject, который преобразует объект Java в указанный тип SQL перед отправкой значения в базу данных.

Эта формулировка больше не присутствует в последних спецификациях JDBC, но ее намерение по-прежнему применяется и определяется в приложении B.2 в JDBC 4.3.

Однако на практике многие драйверы JDBC, включая MySQL Connector/J, поддерживают более широкий диапазон преобразований, аналогичный тому, который определен для setObject в приложении B.5, хотя каждый драйвер имеет свои оговорки и причуды здесь. Для Long это означает, что getObject может TINYINT, SMALLINT, INTEGER, BIGINT, REAL, FLOAT, DOUBLE, DECIMAL, NUMERIC, BIT, BOOLEAN, CHAR, VARCHAR, LONGVARCHAR, и это, как правило, означает, что вы можете сделать то же самое с setLong,

Это также обеспечивает единообразие конверсий для getLong определенных в добавлении B.6.

Независимо от того, имеет ли он какие-либо недостатки, зависит от реализации. Драйвер MySQL Connector/J является открытым исходным кодом, поэтому, если вы хотите узнать подробные подробности: посмотрите на источник.

Однако, если ваше приложение на самом деле использует long, то почему это тип базы данных INTEGER? Либо используйте BIGINT в своей базе данных для соответствия вашему приложению, либо используйте int в своем приложении для соответствия базе данных.