При доступе к ResultSets в JDBC, там изящный способ различать пустые указатели и фактические нулевые значения?

При использовании JDBC и доступе к типам примитивов через набор результатов, там более изящный способ иметь дело с пустым указателем/0, чем следующее:

int myInt = rs.getInt(columnNumber)
if(rs.wasNull())?
{
 // Treat as null
} else
{
 // Treat as 0
}

Я лично съеживаюсь каждый раз, когда я вижу этот вид кода. Мне не удается видеть, почему ResultSet не был определен, чтобы возвратить помещенные в коробку целые типы (кроме, возможно, производительность) или по крайней мере предоставить обоим. Бонусные очки, если кто-либо может убедить меня, что текущий дизайн API является большим :)

Мое персональное решение состояло в том, чтобы записать обертку, которая возвращает Целое число (я забочусь больше об элегантности клиентского кода, чем производительность), но я задаюсь вопросом, пропускаю ли я лучший способ сделать это.

Просто для уточнения, что беспокоит меня об этом коде, не длина, но то, что это создает зависимость состояния между последующими вызовами, и что появляется как простой метод считывания на самом деле, имеет побочный эффект в той же строке.

5
задан Uri 6 May 2010 в 01:49
поделиться

1 ответ

API JDBC был разработан для производительности. Помните, что он восходит к Java 1.1, когда большой оборот объектов был убийцей JVM (только в Hotspot JVM в Java 1.2+ можно было ослабить такого рода ограничения). Использование коробочных типов в то время разрушило бы производительность высокопроизводительных приложений.

Теперь это нельзя изменить из-за обратной совместимости. Так что нет, это уже не идеальный вариант, но это довольно незначительная вещь, которую можно обойти.

Если вы хотите избежать упомянутого вами типа кода, вы всегда можете использовать getObject() вместо getInt(), который вернет объект одного из подтипов java.lang.Number, вероятно Integer или BigInteger, в зависимости от конкретного типа SQL.

8
ответ дан 14 December 2019 в 04:32
поделиться
Другие вопросы по тегам:

Похожие вопросы: