Подгружаемый делегат - реально?

[Bepec]

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

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

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

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

[Hellraiser]

Насчет такого делегата не скажу, но может лучше возложить такую работу на СУБД? К примеру, если текст первого столбца как-то зависит от второго (сумма < 10000 - пишем "денег мало"), или, вообще, константен, то можно на стороне сервера организовать вьюху и пусть она вернет оба столбца. Ну а далее взять SQL модель...

[Bepec]

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

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

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

PS ладненько, вопрос закрывается. Попробую сделать, результат отпишу тут же.

[schmidt]

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

1. Пишем свою QSortFilterProxyModel с переменным счетчиком-ограничителем строк (rows_display_cnt) с некоторым начальным значением, равным количеству строк, видимых в QTableView при первом отображении без прокрутки (пусть будет 7).
2. Перехватываем wheelEvent() у QTableView и проверяем, хотел ли юзверь прокрутить таблицу и увидеть следующие строки. Если да, подтягиваем ограничитель у QSortFilterProxyModel выше, чтобы фильтр пропускал больше строк.

[Bepec]

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

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

По аналогии с тоталом - выделяется 10 папок. Они последовательно считаются и появляется их размер. Опять таки последовательно.

[Old]

Делегаты здесь никак.
Все это должна делать модель.

[Bepec]

Печалька ) В принципе у меня подгрузка получилась, только вот нестабильная. Ибо при исчезновении с экрана эта инфа уже не нужна. То там утечечка, то неверные значения

[schmidt]

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

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

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

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

Тогда вариант с бесконечной прокруткой вам вряд ли подойдет.

[Bepec]

Модель собственно должна хранить данные. А я не хочу их хранить. Я хочу, чтобы они создавались, хранились и умирали только в моменты видимости

[Old]

Модель собственно должна хранить данные.

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

[Странник]

Модель собственно должна хранить данные. А я не хочу их хранить. Я хочу, чтобы они создавались, хранились и умирали только в моменты видимости

модель должна возвращать запрошенные данные по обращению, а уж откуда она их берет - это ее личное, модели, дело.

[Bepec]

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

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

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

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

update: не, даже не так. Написание пустой модели с рассчитывающим делегатом

[_OLEGator_]

Данные для третьей колонки все-таки должна предоставлять модель.

[Bepec]

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

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

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

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

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

А то SqlTable/Relation модели требуют подгружать весь контент.

[schmidt]

Из документации:

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 ..." для ограничения количества выводимых строк.