А.Грасоff™ GMaxКак грамотно определить количество строк в полученном ResultSet?

В книге "Сервлеты и JavaServer Pages" написано:
"Единственный способ определения количества строк - постоянное повторение вызова метода next объекта ResultSet, пока он не возвратит значение false".

Неужели только так?

ResultSet rs = con.createStatement(ResultSet.TYPE_SCROLL_INSENSITIVE, ResultSet.CONCUR_READ_ONLY).executeQuery(qry);
rs.last();
int resulSetSize = rs.getRow();
rs.beforeFirst();
Ну ты научишь, Граспых. Память-то не резиновая.

MBasilКурсор Oracle обеспечивает последовательный доступ только в одном направлении (несмотря на скроллируемость резервного набора).
Поэтоу предложенный метод пройти до конца, а потом вернуться в начало приведет только к повторному выполнению запроса и перебору всех строк, но скрытым образом.
То есть сначала все строки извлекаются на клиента, а потом выполняется повторно запрос и в полученном НОВОМ наборе курсор устанавливается в начало.Это ты сам придумал? Или это где-то написано? Как объяснишь вот это:

zalexaka2 stdio
а версия thin драйвера у вас какая?9.0.1.5.0
На других версиях, думаю, поведение будет точно таким же.

MBasilto stdio
Ну, и как это противоречит тому, что я написал ?
Когда ты вызвал execute(), выполнился парсинг SQL и было произведено его выполнение.
Указатель курсора установлен на начало для выборки.
Когда ты вызвал rs.last() все строчки должны быть "профетчены" на клиента, что естественно потребовало массу работы.
В чем ошибочность моих слов ?
Проблема этого дела в том, что не пройдя весь курсор с фетчем до конца ты не узнаешь, сколько возвращено строк.
Это принципиальный вопрос, так как узнать количество строк в Oracle можно только перебрав их все.
Вернуться в начало - значит повторно выполнить запрос.
Чем тебе не нравиться COUNT(*). Запрос, конечно все равно выполняется, но хоть фетч уменьщается до одной строки.
И дело тут не в версии драйвера, а в механизме работы курсора Oracle.противоречит тем, что ты рассказываешь про то как работает драйвер, как ты думаешь, а не так как Oracle это делает на самом деле . А на деле он просто скачивает всё в память на клиента и там уж создаёт иллюзию обратно крутимого курсора.

MBasilТаким образом задача stdio видимо состояла не в том, чтобы ответить на вопрос, как без выполнения операции фетч выяснить - сколько строк вернет запрос, а в том чтобы уличить меня в ошибке.Нет. Я просто хотел показать, что лучше один раз провести эксперимент, чем строить гипотезы. Даже если будет SENSITIVE, то совсем не очевидно, что будет перезапускаться весь запрос целиком. Не будет вылняться select * from (...) where rowid = ... ? А? А под хранение значений "предыдущих" rowid всё равно память нужна => всегда я найду такую таблицу, на которой оперативной памяти не хватит.
_________________
Умерщвление прекрасной гипотезы мерзким фактом являет собой величайшую трагедию науки

MBasilПолагаю, что при перезапросах ROWID использоваться не будет, так он неизвестен для вставленных после первого запроса строк.
Поэтому Вашу замечательную сентенцию по поводу красивой гипотезы возвращаю Вам обратно."To support updatability and change sensitibility, Oracle JDBC drivers cache the ROWID along with each row". (взято из читаемого курса по "Oracle9i: Access the Database with Java and JDBC"). Проверять - проверял до курса.
MBasilИзвините за назойливость. Маленькое дополнение
У меня есть небольшая универсальная программа по выполнению запросов и выводу результатов написанная на Java.
В ней запрос (Oracle 10g )

SELECT * FROM dba_objects;

возвратил строк : 48259 За время : 12344 м-сек.

Запрос

SELECT COUNT(*) FROM dba_objects;

возвратил строк : 1 За время : 203 м-сек.

Правда это с учетом вывода на экран. Однако, согласитесь, разница во времени существенная.
Поскольку я принципиально не использую чувствительных к скроллированию курсоров, потребность в памяти при десятках подряд выполняемых запросов составляет 12М и не больше.
Что касается скроллируемых наборов, то предпочитаю собственного изготовления RowSet с кэшированием строк в базе, расположенной на сервере приложений.Ах, ну всё про баню. Я где-то утверждал, что надо пересчитывать строки на клиенте?

MBasilГоспода, обращаю ваше внимание на некоторые дополнительные аспекты.Типа, пусть мировое сообщество нас рассудит?
MBasil1. То, что для изменения строки, еще в момент выполнения операции POST и в момент ее блокирования необходимо кэширование ROWID, это несомненно, как несомненно и то, что драйвер обязан это делать.До этого Вы выдвигали совсем другую гипотезу. http://www.sql.ru/forum/actualpost.aspx?bid=38&tid=141321&mid=1149935&p=1&act=quot#1146913
MBasil2. Однако, рассмотрим следующую ситуацию. Пользователь работает с последними строками резервного набора, а в это время администратор удаляет одну из первых строк и вставляет ее вновь. При этом он еще вставляет десяток строк (одна из них может получить то же самое ROWID). Можете ли Вы гарантировать, что по ROWID будет получена та же строка, когда пользователь вернется в начало набора ? Фиксация ROWID ведь гарантирована только при блокировании строки. Представьте себе - пользователь проскроллировал набор в начало увидел на месте старой строки нечто совершенно неожиданное, так как ROWID старой строки получила другая.
3. Ситуация практически та же, но запрос обращается к секционированной таблице, а администратор выполняет операции MERGE PARTITION или SPLIT PARTITION.
Можно было бы привести и другие примеры, но думаю и этого достаточно.Выводы где? Смотрим в документацию и видим: http://download-west.oracle.com/docs/cd/B10501_01/java.920/a96654/resltset.htm#1020090
Повторюсь "Умерщвление прекрасной гипотезы мерзким фактом являет собой величайшую трагедию науки"
MBasil4. Откровенно говоря менторский тон stdio мне надоел, и с Вашего разрешения, я в дискуссию по этому топику больше вмешиваться не буду. Пусть последнее слово останется за ним.И пусть ему будет стыдно!