ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Java [игнор отключен] [закрыт для гостей] / JDBC: setNull не катит для SELECT?
19 сообщений из 19, страница 1 из 1
JDBC: setNull не катит для SELECT?
    #34316998
Дм.Смирнов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Дм.Смирнов
Гость
Может конечно глупый вопрос, но ...

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
        DriverManager.registerDriver( new  oracle.jdbc.driver.OracleDriver());
        Connection c = DriverManager.getConnection("jdbc:oracle:thin:...", "argus_admin", "argus");
        c.setAutoCommit(false);
        PreparedStatement s = c.prepareStatement("select count(*) from tbl where col = ?");
        s.setNull( 1 , java.sql.Types.INTEGER);
        ResultSet rs = s.executeQuery();
        rs.next();
        System.out.println("Null: " + rs.getInt( 1 ));
        rs.close();
        s = c.prepareStatement("select count(*) from tbl where col is null");
        rs = s.executeQuery();
        rs.next();
        System.out.println("Null: " + rs.getInt( 1 ));
        rs.close();
        s.close();

при первом чтении возвращается 0, при втором - реальное количество строк с null значениями
Для insert, update setNull отрабатывает нормально

поиски по докам и интернету не привели к видимому результату
во всех источниках нет нигде явного упомининия о неработе с select

есть какие-то решение для связки null параметров без синтаксического анализа текста запроса и замены "= Null " на "is null"?
...
Рейтинг: 0 / 0
08.02.2007, 18:02:00
| Ответить | Цитировать | Написать  
JDBC: setNull не катит для SELECT?
    #34317115
Фотография Denis Popov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Denis Popov
Участник
Можно попробовать что-то вроде:
Код: plaintext
1.
2.
3.
PreparedStatement s = c.prepareStatement(
  "select count(*) from tbl where nvl (col, -1) = nvl(col, -1)"
);
Подставив вместо -1 число, которого точно не будет среди значений.
...
Рейтинг: 0 / 0
08.02.2007, 18:28:58
| Ответить | Цитировать | Написать  
JDBC: setNull не катит для SELECT?
    #34317139
carper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
carper
Гость
select count(*) from tbl where col = null

Ничего не вернет, т.к. сравнение с null таким образом запрещено, точнее неопределено ( в зависимоcти от реализации СУБД реакция может теоретически быть вообще любая).

В переводе на язык базы вы просите ее сравнить что-то конкретное с чем-то вообще неизвестным, например, 1> неизестно чего, 1< неизестно чего, 1==неизвестно чему?

Или null==null? А фиг его знает, что в реальности скрывается за первым неизвестно чем и вторым неизвестно чем. :)

Вот именно для того, чтобы вы могли объяснить, что сравнивать ничего не надо, а надо просто выбрать ряды с неизвестным значением и введено is null.


"поиски по докам и интернету не привели к видимому результату"
Если открыть любую самую примитивную книжку по СУБД этот нюанс расписывается самыми жирными буквами. Не надо было просто использовать в поиске слова типа JAVA, т.к. это к ней не имеет никакого отношения. :)
...
Рейтинг: 0 / 0
08.02.2007, 18:36:31
| Ответить | Цитировать | Написать  
JDBC: setNull не катит для SELECT?
    #34317142
Дм.Смирнов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Дм.Смирнов
Гость
так вобщем-то сейчас и поступаю, но это в каждом конкретном случае надо делать предположения о том, "а может ли здесь быть NULL" (а не хочется так), да и планы выполнения запросов может отчасти портить
я сделал обертку на setXXX, setNull, в которой проверяю значение параметра и не думая больше о параметрах вызываю ее
а получается, что SELECT чем-то оказался обижен в JDBC
но вроде и в ODAC это наблюдается
вот только пока не могу понять, отчего оно так
пытаюсь найти решение без переписи запросов
...
Рейтинг: 0 / 0
08.02.2007, 18:36:39
| Ответить | Цитировать | Написать  
JDBC: setNull не катит для SELECT?
    #34317163
Фотография Denis Popov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Denis Popov
Участник
Дм.Смирнов wrote:

> да и планы выполнения запросов может отчасти портить

Индекс по функции может спасти.
Posted via ActualForum NNTP Server 1.3
...
Рейтинг: 0 / 0
08.02.2007, 18:41:41
| Ответить | Цитировать | Написать  
JDBC: setNull не катит для SELECT?
    #34317164
Зашедший
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Зашедший
Участник
Дм.Смирнова получается, что SELECT чем-то оказался обижен в JDBC

В каком смысле "обижен"? Нельзя через JDBC сделать что-то, что не поддерживается непосредственно в SQL. Логично, разве нет?
...
Рейтинг: 0 / 0
08.02.2007, 18:41:48
| Ответить | Цитировать | Написать  
JDBC: setNull не катит для SELECT?
    #34317166
Дм.Смирнов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Дм.Смирнов
Гость
автори введено is null
про "=NULL" и "IS NULL" понимаю
сам иногда кому-нибудь рассказываю

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

в старой клиентской библиотеке приходилось делать синтаксический анализ текста запроса перед посылкой на сервер. Но коряво ведь все это
...
Рейтинг: 0 / 0
08.02.2007, 18:42:35
| Ответить | Цитировать | Написать  
JDBC: setNull не катит для SELECT?
    #34317169
carper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
carper
Гость
Denis PopovМожно попробовать что-то вроде:
Код: plaintext
1.
2.
3.
PreparedStatement s = c.prepareStatement(
  "select count(*) from tbl where nvl (col, -1) = nvl(col, -1)"
);
Подставив вместо -1 число, которого точно не будет среди значений.

Смысл?
Ввести в программу неожиданное поведение при возможном изменении структуры таблицы?
Замедлить запрос путем вызова функций?
Озадачить дальнейших разработчиков "волшебной" цифрой в запросе?
Кричать потом на других разработчиков, что "тут вот у меня священное -1, кто покусится убью!"?.

чем is null не угодил? Нежеланием проверить аргумент и слегка изменить запрос при null значении?
...
Рейтинг: 0 / 0
08.02.2007, 18:43:04
| Ответить | Цитировать | Написать  
JDBC: setNull не катит для SELECT?
    #34317181
carper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
carper
Гость
Дм.Смирнов автори введено is null
про "=NULL" и "IS NULL" понимаю
сам иногда кому-нибудь рассказываю

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

в старой клиентской библиотеке приходилось делать синтаксический анализ текста запроса перед посылкой на сервер. Но коряво ведь все это

Коряво, если JDBC драйвер будет соглашаться принимать кривой запрос и "исправлять" его по собственному усмотрению.

Вы же сами потом будете говорить, про кривой драйвер, который "вещь в себе", а он, бедняга, просто решил "додумать" за вас еще пару вещей, ну там хинт оптимизатору подсунуть , еще чего "по-мелочи". :)
...
Рейтинг: 0 / 0
08.02.2007, 18:46:17
| Ответить | Цитировать | Написать  
JDBC: setNull не катит для SELECT?
    #34317204
Фотография Denis Popov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Denis Popov
Участник
carper wrote:

> Нежеланием проверить аргумент и слегка изменить запрос при null значении?

Думаю, невозможностью или затруднительностью менять запрос при null значении.
Например, когда он - запрос - довольно сложен и/или пришел со стороны.
"Священное" число можно не пускать ограничением в БД. Функция - да, будет, но и
индекс тоже.
Posted via ActualForum NNTP Server 1.3
...
Рейтинг: 0 / 0
08.02.2007, 18:55:00
| Ответить | Цитировать | Написать  
JDBC: setNull не катит для SELECT?
    #34317205
Дм.Смирнов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Дм.Смирнов
Гость
автор"исправлять" его по собственному усмотрению
ну на то есть документация

в том виде, в котором сейчас есть - то же мало приятного
что хочется:
1. сделать PreparedStatement
2. пол лимона раз сделать Bind/Execute

а так пока варианты:
1. держать по несколько парсенных курсоров (если есть null, если нет Null). А если полей несколько в запросе?
2. Править запрос, добавля туда nvl() на все подозрительные поля
3. каждый раз делать анализ запроса и полность гонять цикл: prepare-bind-execute

ни один из них не кажется красивым
неужели остается только выбырать из нескольких зол меньшее и красивых решений здесь не существует?
...
Рейтинг: 0 / 0
08.02.2007, 18:55:07
| Ответить | Цитировать | Написать  
JDBC: setNull не катит для SELECT?
    #34317277
Фотография Timm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Timm
Участник
Дм.Смирнов...
неужели остается только выбырать из нескольких зол меньшее и красивых решений здесь не существует?
Избавиться от NULL-значений в таблицах :)
...
Рейтинг: 0 / 0
08.02.2007, 19:16:59
| Ответить | Цитировать | Написать  
JDBC: setNull не катит для SELECT?
    #34318222
carper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
carper
Гость
Дм.Смирнов
неужели остается только выбырать из нескольких зол меньшее и красивых решений здесь не существует?

Существует, боюсь только, что вы меня за это побьете. :)

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

А попытка "замаскировать" запрос nvl функцией приведет к тому, что мы вытянем хвост - решим вопрос с парсингом, зато увязнем голову - даже когда нет NULL по своей собственной воле получаем наихудшую производительность.

Наименее "кровавый" вариант, уже предложили - если у вас предполагается частое обращение к таблице с null величинами, то стоит задуматься о том чтобы их убрать уже в самой таблице.
Если у вас философский смысл понятия того, что значение "не определено", действительно имеет смысл, то это кривой вариант, т.к. невольно вовлекает человеческий фактор, но из всех неверных самый верный. :)
И убрать null правильнее именно на уровне таблицы, а не JAVA кода или драйвера.


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

Кстати, исходя из теории парадоксального мышления, покопайтесь в последних версиях драйверов, высока вероятность. что уже нашелся "умник", который "облегчил" вам жизнь и таки засандалил такую возможность на уровне драйвера (не обольщайтесь, если найдете, СУБД пофигу ваш драйвер, просто в этом варианте она будет тормозить уже по его вине :( )
...
Рейтинг: 0 / 0
09.02.2007, 11:06:11
| Ответить | Цитировать | Написать  
JDBC: setNull не катит для SELECT?
    #34318329
Дм.Смирнов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Дм.Смирнов
Гость
авторСуществует, боюсь только, что вы меня за это побьете. :)
да нет же :)
интересуют все мнения

зачастую null значения очень даже полезны и убирать их не хочется (или маскировать dummy-значениями)
к примеру хранение набора полей: фамилия, имя, отчество
или: id улицы, №дома, корпус

был опыт работы в старой версии системы, где как раз и осуществлялась поппытка уйти полностью от null полей. И там, к примеру, значение корпуса здания, если оно не указано, проставлялось как "-1". Что из этого получилось: решили проблемы в БД, сделали проблемы клиенту в виде непонятных "-1", там где разработчик забыл сделать обработку магического числа "-1". А приходят новые люди, и этого естественно не знают. Со временем в системе накапливается СТОЛЬКО неявных зверей, подобных "если ... то ..." (на разных уровнях системы), то становится как-то старшно за масштабируемость и безглючность

Вот и получается, что в одном месте деалем красиво, в другом - сложности.
Хотелось найти решение, при котором разработчик со стороны клиента при виде поля не должен задаваться мыслью, "а надо ли мне именно для этого поля что-то еще дополнительно сделать, что бы не вылезло какой-нибудь ерунды у заказчика"
Или, с другой стороны, разработчик БД/клиента при написании запроса/ХП не должен задумываться о том, а допустимо ли здесь null-значение и надо ли сделать опыть же какие-то телодвижения.
Задание ограничений NULL/NOT_NULL не всегда подходит из-за частой смены требований к сущностям автоматизации
Получается очень много мест, в которых надо о чем-то помнить.

Похоже, что это вопрос уже не технический, а больше организационно-проектировочный: как сделано? кто должен помнить о том, что сделано? кто кому должен доносить информацию о том как надо делать?

А технические решения есть Null, нет Null не сильно отличаются друг от друга автор
...
Рейтинг: 0 / 0
09.02.2007, 11:27:48
| Ответить | Цитировать | Написать  
JDBC: setNull не катит для SELECT?
    #34318752
carper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
carper
Гость
Дм.Смирнов
Похоже, что это вопрос уже не технический, а больше организационно-проектировочный: как сделано? кто должен помнить о том, что сделано? кто кому должен доносить информацию о том как надо делать?

А технические решения есть Null, нет Null не сильно отличаются друг от друга

Совершенно верно, это вопрос реализации бизнес-логики.
Можно обойти ее на кривой кобыле, но потом, вы сами все верно описали, что вылезает.

Поскольку первичен потребитель, а не исполнитель, то я бы рекомендовал решать каждую проблему индивидуально и, ни в коем случае не идти по пути превращения всего и вся в метаобъекты с реализацией наихудшего по производительности, зато "универсального", варианта.

Все эти nvl надо не надо и т.п. до добра не доведут и, в конечном итоге, загрузят базу больше чем повторные разборы.
А что бывает при замене значимых null на "умолчания" вы и сами все прекрасно описали.
...
Рейтинг: 0 / 0
09.02.2007, 12:43:22
| Ответить | Цитировать | Написать  
JDBC: setNull не катит для SELECT?
    #34318812
Дм.Смирнов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Дм.Смирнов
Гость
большое спасибо всем участникам дискуссии
буду думать ...
...
Рейтинг: 0 / 0
09.02.2007, 12:51:33
| Ответить | Цитировать | Написать  
JDBC: setNull не катит для SELECT?
    #34320001
TiG
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
TiG
Участник
Denis PopovМожно попробовать что-то вроде:
Код: plaintext
1.
2.
3.
PreparedStatement s = c.prepareStatement(
  "select count(*) from tbl where nvl (col, -1) = nvl(col, -1)"
);
Подставив вместо -1 число, которого точно не будет среди значений.

А чтобы не думать какого-же "точно не будет среди значений":

Код: plaintext
select count( 1 ) from tbl where col = ? or ? is  null  and col is  null
...
Рейтинг: 0 / 0
09.02.2007, 16:31:13
| Ответить | Цитировать | Написать  
JDBC: setNull не катит для SELECT?
    #34320044
Фотография Denis Popov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Denis Popov
Участник
TiG
А чтобы не думать какого-же "точно не будет среди значений":
Код: plaintext
1.
select count( 1 ) from tbl where col = ? or ? is  null  and col is  null

Да, только переменные двоятся, может полететь весь порядок при их привязке.
Posted via ActualForum NNTP Server 1.3
...
Рейтинг: 0 / 0
09.02.2007, 16:45:17
| Ответить | Цитировать | Написать  
JDBC: setNull не катит для SELECT?
    #34320315
TiG
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
TiG
Участник
Denis PopovДа, только переменные двоятся, может полететь весь порядок при их привязке.

Ну да есть недостатки у позиционного binding-а :)
...
Рейтинг: 0 / 0
09.02.2007, 18:21:43
| Ответить | Цитировать | Написать  
19 сообщений из 19, страница 1 из 1
Форумы / Java [игнор отключен] [закрыт для гостей] / JDBC: setNull не катит для SELECT?
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=59&gotonew=1&tid=2146684]:
 0ms
get settings:
 8ms
get forum list:
 19ms
check forum access:
 6ms
check topic access:
 6ms
track hit:
 75ms
get topic data:
 11ms
get first new msg:
 6ms
get forum data:
 2ms
get page messages:
 51ms
get tp. blocked users:
 1ms
others: 275ms
total:  460ms
созд. / загр.: 460ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]