Russian Qt Forum
Ноябрь 01, 2024, 05:35 *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

Войти
 
  Начало   Форум  WIKI (Вики)FAQ Помощь Поиск Войти Регистрация  

Страниц: [1] 2   Вниз
  Печать  
Автор Тема: Подгружаемый делегат - реально?  (Прочитано 12241 раз)
Bepec
Гость
« : Март 12, 2013, 08:50 »

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

К примеру - таблица 2 столбца текстовых. Первый статичен и не меняется. Данные для второго необходимо подгружать из бд.

Возможно ли сделать автоподгрузку данных? Т.е. прокрутили таблицу дальше - подгрузились значения только для видимых элементов. И так далее.

Пока сумбурно мыслю, алгоритм не выстраивается.
Вопрос в возможности такой реализации, на ваш взгляд.
Записан
Hellraiser
Бывалый
*****
Offline Offline

Сообщений: 451


Просмотр профиля
« Ответ #1 : Март 12, 2013, 12:27 »

Насчет такого делегата не скажу, но может лучше возложить такую работу на СУБД? К примеру, если текст первого столбца как-то зависит от второго (сумма < 10000 - пишем "денег мало"), или, вообще, константен, то можно на стороне сервера организовать вьюху и пусть она вернет оба столбца. Ну а далее взять SQL модель...
Записан
Bepec
Гость
« Ответ #2 : Март 12, 2013, 12:55 »

У меня данные выходят за область базы Веселый

Берётся файл, считается хеш, запрашивается из базы наличие или отсутствие хеша. Если имеется, то заносится в таблицу и... И вот тут прикол. Колонки хеша и пути к файлу берутся из 2 таблиц sql. И возникает необходимость выдать доп инфо, аля атрибуты файла, размер, последнее изменение, дата создания Веселый

Для 5 миллионов хранить эти данные в памяти как бы накладно Веселый Потому и думается мне сделать делегатик, чтобы информация не улетала за 2 гига данных Веселый

PS ладненько, вопрос закрывается. Попробую сделать, результат отпишу тут же.
Записан
schmidt
Гость
« Ответ #3 : Март 12, 2013, 21:55 »

Делегат здесь вряд ли подойдет Улыбающийся Здесь напрашивается использование QSortFilterProxyModel. Я бы сделал следующим образом:

1. Пишем свою QSortFilterProxyModel с переменным счетчиком-ограничителем строк (rows_display_cnt) с некоторым начальным значением, равным количеству строк, видимых в QTableView при первом отображении без прокрутки (пусть будет 7).
2. Перехватываем wheelEvent() у QTableView и проверяем, хотел ли юзверь прокрутить таблицу и увидеть следующие строки. Если да, подтягиваем ограничитель у QSortFilterProxyModel выше, чтобы фильтр пропускал больше строк.
Записан
Bepec
Гость
« Ответ #4 : Март 12, 2013, 21:58 »

Кхм. Мб непонятно написал, но информация должна получаться не из модели.
Цитировать
У меня данные выходят за область базы

По аналогии с тоталом - выделяется 10 папок. Они последовательно считаются и появляется их размер. Опять таки последовательно.
Записан
Old
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 4350



Просмотр профиля
« Ответ #5 : Март 12, 2013, 22:20 »

Делегаты здесь никак.
Все это должна делать модель.
Записан
Bepec
Гость
« Ответ #6 : Март 12, 2013, 22:36 »

Печалька ) В принципе у меня подгрузка получилась, только вот нестабильная. Ибо при исчезновении с экрана эта инфа уже не нужна. То там утечечка, то неверные значения Веселый
Записан
schmidt
Гость
« Ответ #7 : Март 13, 2013, 07:36 »

А если обратиться к юзабилити - много ли найдется пользователей, которые будут счастливы вращать колёсиком 5млн строк? Улыбающийся Я бы сделал выбор в пользу постраничного виджета с полем текстового фильтра и возможностью сортировки по столбцам. Для переключения по страницам останется только менять FirstItemIdx и LastItemIdx у вашей SortFilterProxyModel и вызывать reset(), чтобы избавиться от ставших ненужными "висящих" в View данных.

Цитировать
информация должна получаться не из модели.

А почему нет? Модель - это только обертка, frontend для данных. Научите модель динамически связываться с базой и извлекать из нее данные. Станет проще жить, сможете легко пользоваться всеми остальными удобствами Qt Model/View Framework Улыбающийся

Цитировать
при исчезновении с экрана эта инфа уже не нужна

Тогда вариант с бесконечной прокруткой вам вряд ли подойдет.
Записан
Bepec
Гость
« Ответ #8 : Март 13, 2013, 08:26 »

Модель собственно должна хранить данные. А я не хочу их хранить. Я хочу, чтобы они создавались, хранились и умирали только в моменты видимости Подмигивающий
Записан
Old
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 4350



Просмотр профиля
« Ответ #9 : Март 13, 2013, 08:42 »

Модель собственно должна хранить данные.
Нет, модель должна удобно представлять данные для гляделки. Хранить данне должна база данных.
Записан
Странник
Гость
« Ответ #10 : Март 13, 2013, 09:48 »

Модель собственно должна хранить данные. А я не хочу их хранить. Я хочу, чтобы они создавались, хранились и умирали только в моменты видимости Подмигивающий
модель должна возвращать запрошенные данные по обращению, а уж откуда она их берет - это ее личное, модели, дело.
Записан
Bepec
Гость
« Ответ #11 : Март 13, 2013, 12:02 »

В принципе всё удалося Веселый

Переписал начисто проект - проблемы ушли.

В результате имеем таблицу с 3 колонками. Третья рассчитывается в делегате Улыбающийся Минимальные затраты, нет необходимости что-то выкручивать в модели.

Сейчас происходит проба написания SQL модели без использования Qsqltable*.

update: не, даже не так. Написание пустой модели с рассчитывающим делегатом Веселый
« Последнее редактирование: Март 13, 2013, 12:15 от Bepec » Записан
_OLEGator_
Гость
« Ответ #12 : Март 13, 2013, 13:53 »

Данные для третьей колонки все-таки должна предоставлять модель.
Записан
Bepec
Гость
« Ответ #13 : Март 13, 2013, 14:03 »

Зачем грузить стандартную модель нестандартными функциями?

Конечно это риторический вопрос.

У меня там используется QSqlTableModel. Три колонки - две текстовые и одна с уникальным идентификатором. Делегат берёт уник, далее делает чудо и отображает натуральные данные о файле. Модель при этом стандартна и не переопределена.

PS задам и тут вопрос - модель-view для ездинья по SQL в комплекте Qt нету чтоли?

Ездить имею в виду - не загружать все данные, а хранить в себе только начало и конец текущего отрезка и загружать данные на лету из БД.

А то SqlTable/Relation модели требуют подгружать весь контент.
Записан
schmidt
Гость
« Ответ #14 : Март 13, 2013, 19:34 »

Из документации:
Цитировать
void QSqlTableModel::setFilter ( const QString & filter ) [virtual]

Sets the current filter to filter.

The filter is a SQL WHERE clause without the keyword WHERE (for example, name='Josephine').

If the model is already populated with data from a database, the model re-selects it with the new filter. Otherwise, the filter will be applied the next time select() is called.

Говорят, можно передать ему SQL'ную строку "1 LIMIT ..." для ограничения количества выводимых строк.
Записан
Страниц: [1] 2   Вверх
  Печать  
 
Перейти в:  


Страница сгенерирована за 0.051 секунд. Запросов: 23.