carper Vladimir Kozlov
А я вот никак понять не могу - даже при суперумном гриде (кстати, энтузиастам DevExpress рекомендую отселектить 200000 записей и включить в гриде фильтрацию) - неужели найдется такой пользователь который осилит все 200000 в гриде просмотреть? :)

Да не осилит никто, это все тайно понимают. Но иначе ведь придется ломать голову как клиенту не дать этого сделать не вызвав неудовольствия последнего, а психология это слабое место программистов. :)


Да тут даже не психология нужна а книги по юзабилити :)

carper

А какие при этом финты ушами вытворяет ADODataset в связке с MSSQL - вообще не передать словами...

А какие, а то я не разбирался? Что-то особенного? :)


На больших запросах - таки да, вплоть до наглого пожирания виртуальной памяти в момент открытия датасета. Шаманство с серверными курсорами тоже не всегда помогает. А вот SQLDirect от российского автора работает на тех же запросах прекрасно.

carper

Но можно написать своё. Да, время теряется, которое можно было бы потратить на собственно логику программы. Но - время теряется один раз. Пишешь один раз - юзаешь везде.

Просто далеко не всем это нужно, а вхождение новичка в JAVA неоправдано замедляет. Чисто психологически очень приятно, когда тебе подставляют надежное плечо, а не бросают в прорубь - может последний метод и хорош, но почему-то мало кому нравится. :)


Согласен. Влезая в жабу нужно быть готовым к тому что попотеть придется.

carper

У меня в наследнике TableModel живет более-менее похожий на дельфийский FieldsCollection :) Ну и соответственно всякие FindField, GetFieldByName, SetFieldByName. А теперь сюрприз - для вычисляемых полей есть флажок - вычислять один раз в пределах жизни модели или при каждом обращении. Причем это где-то там в кишках модели кэшируется и совершенно не озабочивает приложение.
Я бы все же вынес это, хотя бы частично, в шлюз таблицы данных.
А с вычисляемыми данными не совсем понял - зачем флажок?
null - считаем, что-то другое либо пересчитываем, либо нет, в зависимости от флажка?
Я правильно понял?
Если так, то для сложных вычислений IMHO правильное решение, а для простых вычислений, я бы лучше не кэшировал - память тоже штука дорогая.

Нет, с вычисляемыми данными у меня так: если данное поле данной записи уже посчитано - возвращаем из кэша, если не посчитано, считаем и кладем в кэш. Если флажок не выставлен - игнорируем кэш и считаем всегда. Всё это живет в onGetValue, расчет вычисляемых полей вынесен в листенер, которому в эвенте приезжает имя поля и номер строки в модели.

А что ты под шлюзом имеешь в виду? У меня наследник AbstractTableModel, в котором живут собственно данные и информация о полях, т.е. метаданные; там же через интерфейсы подвешены форматтеры и код создания рендереров. Далее он может подключаться к гриду напрямую (в простейшем случае) или через набор статических методов, если требуется кастомизация грида в плане непрокручиваемых столбцов или сгруппированных заголовков.
Всё это получилось прекрасно расширяемым и уже вовсю юзается в тестовой версии проекта :)

carper
Нет, я малек погорячился, здесь настоящий шлюз не причем, точнее не причем в данном контексте.
Мне показался несколько тяжеловатым получающийся класс - возникла мысль о выносе всяких там FieldByName в отдельный класс - далее сработала аналогия по работе шлюза с реальной базой с аналогичными функциями - в общем поток сознания... :)

Собственно сам FieldCollection (содержащий инфу о типах полей и прочие приблуды) вынесен в отдельный класс. У него есть int FindField(String). Экземпляр класса живет в модели. Ну а дальше всё просто :)

softwarer alexx726Дочитал до "Если клиент тянет в GRID даже 1000 записей, то вам надо срочно переделывать логику своей программы." и понял, что отвечать не надо было :))
Не надо. Это стандартная песня. Ровно так же, когда дело доходит до веба, оказывается, что клиенту очень даже удобно (..длинный список глупостей..)

На вебе, кстати, 1000 записей на узком линке - утонченный садизм :)

1024бла-бла-бла
Ну или просто купить типа такого
http://www.jidesoft.com/products/grids.htm

Ни хрена себе контролы!

Кстати Product Bundle по цене вполне конкурентоспособен с девэкспрессом ;)

softwarer Vladimir KozlovНа вебе, кстати, 1000 записей на узком линке - утонченный садизм :)
Особенно с учетом компактности html как средства передачи информации - безусловно.

В html помимо собственно самих данных будут приезжать обрамляющие их теги <td>, <tr> и прочее. Плюс к тому - если нужны какие-то действия по щелчку на строке - еще href, плюс class для css-оформления (и не исключено что для разных td-шек он будет разным, т.е. должен приходить с каждой строкой). Так что в результате объем трафика раза в 2-3 вырастет. Ну это конечно в том случае если втупую плоский html гонять. Если xml передавать и лепить контент на клиенте - опять всё не очень весело, поскольку теги xml-я тоже трафика покушать хотят. Ну хотя с xml-ем полегче будет, но все равно не сахар.
Да и на голых данных, предполагая что вообще тегов никаких нет - если средний размер данных одной строки принять 100 байт - то на 1000 строках это 100кило. Диалапный пользователь от таких страничек быстро озвереет :)

alexx726
Сам автор имеет весьма смутное представление о СУБД (очередная хохма на тему "вставьте UDF-Делающую Упдейт в запрос" меня лично очень сильно рассмешила, шутка принята...)


Могу рассказать тебе где я применяю именно UDF-Делающую Упдейт в запросе.
Итак, есть большой-пребольшой каталог товара. Есть субконто "Фирма" и "место хранения". И есть таблица с бухпроводками двойной записи, формирующаяся при проведении документов. Задача: оперативно получать остатки и себестоимости товара.
Что я сделал: завел таблицу с кэшем остатков/себестоимостей. Навешенный на таблицу проводок триггер на вставку/удаление грохает записи в кэше с кодом товара соответствующим вставляемым/удаляемым записям. Просто втупую вычищает из кэша соответствующие строки.
И есть UDF-ка, которой передается код товара и субконто. Первым делом она смотрит в кэш - если данные есть, значит с момента ее последнего вызова новых проводок с данным товаром не было и старых не удалялось, в этом случае она просто достает данные из кэша и отдает наружу. Если в кэше данных не было - пересчитывает на основании таблицы проводок и кладет в кэш.
В результате, вставив эту удф-ку в селект из таблицы товаров, я прозрачно и быстро получаю текущее состояние склада. Пересчитывать и апдейтить этой удф-ке приходится-то намного меньше, чем просто из кэша доставать; для примера полный селект по каталогу с вытаскиванием в грид 6000 записей в ява-приложении происходит 0.7 секунды, а если предварительно грохнуть весь кэш - 18-20 секунд.

Спросишь - почему я не пересчитываю кэш в триггере на таблицу проводок?
А потому. Потому что в этом варианте реализации я могу, засомневавшись вдруг в правильности расчетов (запущенный случай паранойи), грохнуть кэш и пересчитать заново. Потому что, если вдруг придет в голову добавить расчет по LIFO, я добавлю еще пару строк кода внутри UDF-ки, и при следующем вызове в кэше окажутся дополнительные строки с новыми цифрами безо всякого вмешательства с моей стороны и ручного запуска процедуры перерасчета из-за изменений алгоритма.

В системе - 60 клиентов. Терминалка. Юзеры не жужжат.

softwarer Vladimir KozlovТак что в результате объем трафика раза в 2-3 вырастет.
Это изрядно скромная оценка. Реальная повыше, особенно если не заниматься онанизмом и не экономить байты, называя классы как-нибудь типа p1, p2, p3....


Можно пропускать код перед загрузкой на сервак через самописный обфускатор, который нормальные имена классов поменяет на p1,p2,p3 :)
Кстати, очень нехилый выигрыш удается получить на компрессии (юзаю OpenVPN, там неплохая lzo-компрессия, выигрыш в трафике примерно в 1.8 раза получается по моим тестам).

softwarer
Vladimir KozlovДа и на голых данных, предполагая что вообще тегов никаких нет - если средний размер данных одной строки принять 100 байт - то на 1000 строках это 100кило. Диалапный пользователь от таких страничек быстро озвереет :)
У меня было приложение, где диалапные пользователи сидели на модемах 9600. И ничего, нормально работали, не жаловались, единственно dataset.last() был доработан для возможности прерывания его выполнения.

9600? Круто. А на клиенте был браузер или tty ? :)
Кстати, как ты прерывал с клиента dataset.last() - через ajax-вызов или как?

PlafНу тогда объясни, почему возникают темы вроде этой http://forum.ixbt.com/topic.cgi?id=26:32933 ? Люди что, себе специально в ногу стреляют?

Обрати внимание, что там человек страдает с ADO :) да еще и 300000 записей через адо пытается вытянуть...

Timm funikovyuriПредлагаю создать форум для людей с ломкой после перехода на java с дельфей.
...
Там будут апщаться 2 пэрца. Не будем показывать пальцем кто

Когда человек первый раз пробует закурить - у него кружится голова, тошнит, слабеют ноги... но проходит время - и без сигареты он уже не может. Так же и ява - сначала плюешься, но потом есть риск втянуться. А Минздрав предупреждал :)

Timm
Здесь другой случай.

Да, после палёной водки бордо урожая 1963 года кажется жуткой кислятиной :)