Здравствуйте!
Помогите, пожалуйста, определиться с проблемой и её решением.
Есть веб-аппликейшен на ваадин.
Есть в нем таблица, которая принимает данные в виде List<T>
Данные я получаю примерно так:

Используя для таблицы контейнер, а именно IndexedContainer, который предоставляет Vaadin, я подгружаю весь список в память, как я понимаю, клиента. То есть ленивая подгрузка как бы и не присутствует. Я ведь прав? Или не совсем.
Попробовал использовать BeanItemContainer, сразу же получил ошибку от хибернейта:


Что, как я понимаю логично, ведь у меня em.close();
Убрал я в блоке файналли этот close, и все данные отобразились без ошибки.

Прочитал, что IndexedContainer и BeanItemContainer, эти контейнеры как описано: An in-memory container for JavaBeans.
То есть не держат сессию открытой, а подгружают в память, как я понял, если правильно понял.

У Vaadin есть аддон, называется Lazy Query Container, как я понял, он поддерживает ленивую подгрузку, почитал его описание, но пока его особенности не совсем понял. Еще краем глаза читал про эклипсЛинк, но не стал вникать.
В общем не совсем понимаю, саму суть этих всех контейнеров, в частности в связке их с хибернейтом и моим способом получения листа данных, которые я контейнеру передаю, может кто-то вкратце описать общий принцип, как и что лучше использовать.

HettВ DinamicProduct связи есть?

Да есть и они все с явным указанием Lazy, хоть по-умолчанию оно, вроде как, Lazy.

Hett


Про это тоже читал, но пока не стал вставлять в свой persistence.xml, так как толком не вник в этот проперти

HettВ DinamicProduct связи есть?



хоть и в коде получения листа данных я использовал "ненормализованное" с точки зрения БД поле offerId, но это не так уж и важно в контексте этой темы.

UsmanNixicу меня em .close();этот "зверь" должен быть изолирован от UI (:
Вот тут я немного не понял :)
У меня он в методе, которые в отдельном классе, вроде как изолирован от UI :)
или речь о каком-то другом уровне изоляции?

UsmanNixicУ меня он в методе, которые в отдельном классе, вроде как изолирован от UI :)Перечитал первый пост... и понял, что мне не хватило совсем немного телепатических навыков... (:
вобщем, все еще учусь ©
У меня не используется спринг в этом проекте.
Суть вопроса была в описании вкратце работы контейнеров, в частности их работы в режиме Lazy при использовании хибернейт.
С учетом существующего способа выгребания данных из БД, который, возможно стоит как-то изменить.
Все это для того, чтобы отобразить в таблице ваадина 1000+ строк данных, так, чтобы не засорять память клиента и не вызывать при этом тормозов при прокрутке.
Ну и в описании первого поста есть описания моих подвижек в этом направлении, которые, скорее всего, неправильны в силу отсутствия понимая принципов работы с контейнерами, ленивой подгрузкой данных и сессий хибернейта.

UsmanIMHO, как по мне, появление вертикального скролла в таблице - плохо.
Конечно, можно задать кол-во строк на страницу. Обычно к пагинации,
в добавок, припиливается функционал поиска/фильтра - пользователь
захотел найти/отфильтровать кое-какие данные, при этом отпадает
необходимость листать стопицот страниц в поисках чего-то нужного.
Да, абсолютно согласен, но пользователям этим нужная вся портянка, они привыкли к экселю, где 255000 или сколько у него там строк вниз по умолчанию и хотят, чтобы было так же и здесь. Пагинацию я могу добавить и скорее всего попытаюсь позже, но уже используя компонент Vaadin'a Grid, вот только его немного допилят (вроде как скоро уже).
Фильтрацию, конечно же, тоже использую, в данном случае так называемый поиск по названию и по группе товара.

Суть бизнеса для которого я это пишу - продажи. У них бывают большие, с точки зрения времени работы над ними сотрудниками, заявки в 1000-2000 строк товара. Это процентов 10 примерно из всех. Но их тоже нужно отрабатывать. В этом случае пагиннация, особенно если сделать строк по 30 на "страницу" будет не совсем уместна.

Просто я вижу в примерах где используется 1 000 000 строк в таблице, при этом можно соскролиться ближе к концу и отредактировать (вот здесь не уверен, примера не видел) данные в строке. А у меня лажа какая-то уже при 500+ строк с этими лейзи не лейзи :))

Ах да и самая большая "проблема" почему здесь может быть неуместна паггинация - позиции могут повторяться, причем несколько раз во всем списке из 1000 позиций, одни могут быть в начале, другие в конце. И не просто повторяться, а называться по разному, начинаться с разных слов/букв, но по сути это один и тот же товар. Даже отсортировав по имени можно что-то упустить.
Вот поэтому они и бьются за то, чтобы все было на одной странице в таблице. Как в Экселе) Хотя все это дело привычки и внимательности сотрудников.
В общем с лейзи надо все равно что-то делать :)

mad_nazgulNixicАх да и самая большая "проблема" почему здесь может быть неуместна паггинация - позиции могут повторяться, причем несколько раз во всем списке из 1000 позиций, одни могут быть в начале, другие в конце. И не просто повторяться, а называться по разному, начинаться с разных слов/букв, но по сути это один и тот же товар. Даже отсортировав по имени можно что-то упустить.
Вот поэтому они и бьются за то, чтобы все было на одной странице в таблице. Как в Экселе) Хотя все это дело привычки и внимательности сотрудников.
В общем с лейзи надо все равно что-то делать :)

Разницы, в том что человек видит 10 строк и > 10 строк практически никакой.
А Ексель удобен для "сверки" тем что там удобный механизм фильтрации данных.
Дайте гриду с удобной фильтрацией и не нужна будет портянка данных.
На крайний случаей есть стильно-модно-молодежный способ "бесконечного скролинга".
Когда данные отдаются как при пагинации, но просто добавляются вконец.
А передавать туда-сюда портянки данных из 10 000 строк, как-то не правильно.
))))
уффф)) да дам я гриду все фильтры, дам :)
Вопрос-то не в этом совсем. И даже не в том, что надо видеть 250тыс строк сразу на клиенте, кстати это был пример как работают со строками в экселе, что юзерам надо так же чтоб было быстро и чтоб много-много строчек и чтоб еще осталось, ограничимся парой тысяч строк.
Дак вот чтобы они все отображались по мере необходимости, то есть была ленивая подгрузка, что вниз мы крутим, что вверх крутим, все одно и не тормозит. Пагинация не рассматривается, так как она заставляет юзера щелкать мышой лишний раз прицельно, вместо плавного кручения колеса мыши. Вопрос был про контейнеры и их свойства, про их применяемость в том или ином случае, про их особенности в кратце.
А то блин началось, 250000 строк отдаем на клиента и получаем нобелевку )))

Petro123Nixic,
скоро на вторую страницу пойдём.
1. Дай ссылку на таблицу ваадин с ленивой подгрузкой. Помнится они обещали такую сделать пару лет назад.
Сделали?
Если нет, то что ты тут обсуждаешь?
Ага! Ну вот уже, что-то. То есть получается, у компонента Table вообще не может быть ленивой подгрузки?
Пока это писал, решил глянуть, нарыл, что лейзиЛоадинг у Table идет на уровне контейнера. Я точно не уверен что правильно сейчас скажу, но получается, что все зависит от контейнера, в данном случае.
А если брать Grid, то там это уже на уровне компонента реализовано, так получается?
Я вот саму суть работы с контейнерами не понял, именно в отношении ленивой подгрузки. Вот и подумал, что, кто-нибудь вкратце ткнет носом куда надо))
Пока буду рыть спеки и оф.документацию по всем этим делам, может что прояснится в итоге.

Petro123И не сравнивай веб проект с Excell десктоп.
А если надо? :)
Кстати, я не видел как работа с таблицами сделана в 1С, у них же тоже есть веб-поддержка интерфейса какая-то, у них-то явно большие объемы данных и в теории веб должен бы соответствовать десктопной версии ПО.

Поверхностное изучение темы привело меня к следующим выводам:

1. В 8-й версии Vaadin переработали компоненты так, что теперь они из коробки поддерживают лейзиЛоадинг :
This is just the tip of the iceberg. There are many other exciting enhancements coming up. For example, a super easy way of connecting lazy loading components to data without a need to build a custom Container. We believe that Vaadin Framework 8 will make your life as a Java developer much easier.
Делаем вывод, что раньше, то есть в 7-й версии лейзиЛоадинг приходилось подключать через(к) переписанные(м) контейнеры(ам) либо используя готовые аддоны не от команды Vaadin.

2. В 8-й версии Vaadin вообще убрали такой компонент как Table, я это уже знал и из-за этого не перехожу с 7-ки. Потому что:
а) Переписывать дофига.
б) Grid, которым заменили Table не поддерживает пока Drag and Drop, что меня не очень устраивает. Как пишут в оф.блоге, они скоро включат в 8.1 такой компонент как Grid 2.0, который по их словам просто великолепен для данных и поддерживает Drag and Drop. Его можно использовать уже сейчас, но нужно самому его включать в проект, в общем кому интересно, то вот ссылка. пост от 9 апреля 2017.
в) Для Table, который убрали, у меня уже реализовано "раскрашивание" и другие манипуляции со стилями в зависимости от данных, которые в таблице отображаются.

3. Насколько я понял, сам компонент Table не поддерживает ленивой подгрузки, а использует контейнер, чтобы просто отображать данные, и он же отвечает за подгрузку, ленивую или не очень :) . Вот пример использования контейнера IndexedContainer с количеством строк в 1000. Про Lazy ни слова, но, по ощущениям, прокрутка очень резвая и подгружается по мере необходимости.
Но! Если прочитать вот здесь описание Vaadin JPAContainer , то можно заметить, что в описании сказано примерно следующее: BeanItemContainer не поддерживает ленивую подгрузку, чтобы ее использовать, пожалуйста, посмотрите на аддоны Viritin и LazyQueryContainer. На счет IndexedContainer ничего не сказано.
Также я нашел некоторые упоминания о Lazy loading при использовании Hibernate, а это как раз мой случай: Using JPAContainer with Hibernate
Если кто-нибудь объяснит мне разницу между понятиями JPAContainer и IndexedContainer, то я буду очень благодарен :)
Кажется я сейчас сравнил теплое с мягким, так как наткнулся на вот это про JPAContainer и вспомнил, что я его когда-то использовал, чтобы "быстро" создавать формы, и он не имеет отношения к IndexedContainer... или имеет? Вывод мой получился такой, что IndexedContainer не поддерживает ленивую подгрузку.

4. ... тут я еще что-то хотел дописать, но потерял мысль/мысли и запутался во вкладках браузера с открытыми доками, постами в блогах, стэковерфлоу и описаниями аддонов, контейнеров и еще массы всего :)

Petro123Nixic,
А за ползунок у них почему нельзя таскать?
Юзвери опупеют скролл таблы делать
Тогда нужно еще задать вопрос, а знают ли эти юзверы про клавиатуру и про кнопки на ней pg down pg up, а так же home и end.
Если на этот сарказм ответить серьезно, то скорее всего пользователи знают про то, что можно пользоваться и позунком и пространством под и над ним. И скорее всего некоторые из низ знают, что скорость скроллинга можно настроить в ОС.

Подводя итог. Ну почти :)

В целом понял назначение того и того и вон этого...
Но, неужели действительно есть такая проблема у всех веб-UI, как
одновременное использование Lazy loading и Word wrap и, соответственно, автоподбор высоты строк.

У всех (которые я видел) таблиц/гридов при ленивой подгрузке длинные строки обрезаются и ставится многоточие...
Как я понял, эта проблема из-за неадекватного поведения скрола, то есть невозможно заранее просчитать его размер и...
В общем тупик? :)

Petro123NixicКак пишут в оф.блоге, они скоро включат в 8.1 такой компонент как Grid 2.0
пущай поторопятся.
Конкуренты не дремлют:
- миллион строк
http://www.qooxdoo.org/5.0.2/demobrowser/#table~Table_Remote_Model.html
-
http://w2ui.com/web/demos/#!combo/combo-9
посмотрел оба или обои :) фреймворка, что-то там джавой как-то и не пахнет... или я не прав? :)
а так, ничевошные оба, объединить бы их, а то там это есть, а тут то, я имею ввиду компоненты и работа с ними. По крайней мере в демках

Petro123Nixicпосмотрел оба или обои :) фреймворка, что-то там джавой как-то и не пахнет... или я не прав? :)
да. Это JS клиент.
А пользователям не всё равно на каком ЯП?
все, короче, я сдаюсь, ЯП, эксель/веб,пагинация, дофига кода... всё, я кончился на этом.

Всем спасибо за ответы.
Попробовал и LazyQueryContainer и Viritin.

LazyQueryContainer мне показался слишком замудреным с точки зрения написания фильтров и сортировок.
Пришлось добавлять дополнительные классы в код, заняло это прилично времени, так как примеров в интернете очень мало и они не свежие. А официальная документация скудна и так же содержит примеры их старых версий, многих методов нет или они переписаны по другому. ДжаваДоки хоть и есть и свежие, но не несут представления как именно использовать тот или другой класс и его методы совместно с другими, лишь краткое описание(в принципе так оно и должно быть).
Хотя работает отлично, при 1100_с небольшим строках, показал хорошую скорость подгрузки при прокручивании, при переходах в начало и конец таблицы.
В режиме редактирования, когда на каждую строку на определенные столбцы навешаны свои методы через TableFieldFactory,
скорость чуть хуже, но приемлемо.
В диспетчере задач хрома он показал примерно
130-160мб у вкладки с таблицей в обычном режиме и
160-190мб в режиме редактирования.
Возможно чуть больше, в общем до 210мб. При этом вполне возможно еще комфортно работать.

Далее я посмотрел Viritin и его MTable, который расширяет стандартный Table от Vaadin. (на нем, кстати останусь теперь для "проблемных" таблиц)
Подключить его заняло какие-то минуты и все сразу же взлетело. И сортировка и ленивая подгрузка.
При этом таблице достаточно дать коллекцию данных через myTable.setBeans(Collection<T> beans) и она будет использовать её через свой собственный контейнер, который вроде бы называется LazyList , но я не стал вдаваться в подробности, может быть позже.

Теперь немного статистики для тех же данных, того же объема в 1100_с небольшим, объектов, то есть строк в MTable.
При просмотре таблицы, при хаотичной прокрутке, в том числе стрелками клавиатуры, постраничной прокрутке через пейдАп/Даун, хоум и енд (прошу прощения за названия на русском:) ) диспетчер задач хрома показывает примерно те же
140-160мб что и при использовании LazyQueryContainer.
180-210мб в режиме редактирования, вполне крутибильно и кликабельно получается.

Все эти "тесты" были проведены с использованием стилей css, которые включают в ячейках перенос слов, а высота ячейки и соответственно всей строки увеличивается. То есть высота строк становится различной и при просмотре и в режиме редактирования таблицы.
В итоге, все же, я решил, что в данном UI высоту строк сделаю под 2-е строки (если конкретно, то 40px).

Для сравнения: при тех же условиях стандартный IndexedContainer от Vaadin, без ленивой подгрузки, при вдвое меньшем количестве строк, то есть 500, почти сразу же начинает подтормаживать и чем дольше работать с таблицей, тем хуже.
500-600-800мб и выше отображаются в диспетчере задач хрома и это, повторюсь, при объеме вдвое меньшем.

Надо заметить, что для других сущностей/объектов БД, которые содержать меньше полей чем та, которую я тестировал, IndexedContainer работает сносно и даже очень хорошо. Или когда используется гораздо меньше столбцов в самой таблице и без фишек css, которые влияют на высоту строк. И менять его просто так не стоит, если он и так справляется с данными.

п.с. нужно не забывать при работе с Table про такие параметры как table.setPageLength(int) и table.setCacheRate(int), они так же влияют на скорость отображения таблицы и работы в ней/с ней.