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

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

Russian Qt Forum > Forum > Qt > Базы данных > QSqlTreeModel всем миром...
Страниц: [1] 2 3   Вниз
« предыдущая тема следующая тема »
  Печать  
Автор Тема: QSqlTreeModel всем миром...  (Прочитано 30318 раз)
crossly
Гость
« : Ноябрь 11, 2008, 10:38 »
тут было много тем про TreeView и БД.... все же хотелось бы узнать... есть ли у кого нормальный ... допиленый код для работы с этим делом... ??
« Последнее редактирование: Ноябрь 11, 2008, 16:39 от crossly » Записан
ритт
Гость
« Ответ #1 : Ноябрь 11, 2008, 11:37 »
мне тоже интересно. пока выбираю запросом данные в стандардмодель и связываю по паренту, но нужна нормальная модель. если у кого-то есть готовая, поделитесь? а то придётся писать свою с нуля Грустный
Записан
Zmeishe
Гость
« Ответ #2 : Ноябрь 11, 2008, 12:14 »
А что значит нормальная ?
Записан
ритт
Гость
« Ответ #3 : Ноябрь 11, 2008, 12:20 »
на основе QAbstractItemModel/QSqlQueryModel. желательно бы с возможностью редактирования данных...
Записан
Zmeishe
Гость
« Ответ #4 : Ноябрь 11, 2008, 12:41 »
Есть у меня похожая гибрид ужа с ежом. Не айс, но некуда деваться.

SQL вытаскивает верхний уровень и сбрасывает в StandardModel, а в root пишу указатель на SQL model c UserRole+1
Потом ловлю сигнал RowChanged динамически на лету создаю очередную SQL model вытаскиваю следующий уровень и "нахомячиваю"  в standard. Указатель на эту новую sql model опять в текущую row с UserRole+1

Когда надо редактировать показываю диалог с вьюхой, из текущей строки вытаскиваю
указатель на sql model и во вьюху setModel

Получается QStandardItemModel содержащая указатели на кучу линейных sql моделей.

Ещё Тролли накосячили с сигналом RowChanged. В пределах одного парента он высылается, а если юзер кликнул мышкой в строку с таким же номером в другом паренте, то не высылается.

На стоматопроктологию похоже, но ничего лучше не придумал.
Записан
ритт
Гость
« Ответ #5 : Ноябрь 11, 2008, 13:14 »
у меня всё проще (достаточно одного прохода для построения дерева), но тоже не айс - я вообще отдаю предпочтение индекс-бэйзед моделям, а в стандардмоделе ещё и с ролями косяк - она предназначена для всяких комбобоксов, а для своих целей приходится делать доп.проверку чтобы выяснить в какой роли на самом деле хранятся edit, а в какой display...

зы. crossly, переименуй ветку нормально
Записан
Zmeishe
Гость
« Ответ #6 : Ноябрь 11, 2008, 13:27 »
Цитата: Константин от Ноябрь 11, 2008,  13:14
у меня всё проще (достаточно одного прохода для построения дерева)

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

Оно может быть большим, а юзеру надо пару веток поправить. Я ему первый уровень вывел по умолчанию. Потом он может навигационным мышетыканьем заниматься и я буду достраивать по мере необходимости.
А может вызвать диалог поиска. Я ему sql`ем вытащу желаемое в небольшом наборе, он выберет конкретную запись, после чего я динамически дострою нужную ветвь и поставлю курсор на  то, что он выбрал.
Так приложение бытрее работает и память не отжирает, но логика сложная.

Хотя в век дешёвых гигабайтов...
Записан
ритт
Гость
« Ответ #7 : Ноябрь 11, 2008, 13:48 »
я тоже не говорю о построении дерева "сразу". я сказал про "один проход". fetchMore ещё никто не отменял...
с другой стороны, всегда хочется по-быстрее избавиться от квери и по возможности пользовать кэш...но увы...

диалог поиска уже не относится к вопросу о модели, но я бы сделал чуть иначе: отдельным запросом можно найти необходимую строку, а из неё уже узнать родителя и уровень вложенности и по этим данным звать fetchMore для определённой ветки, если необходимо...
в целом это даст возможность искать данные и непосредственно в модели без значительных потерь производительности и дополнительных запросов и/или инструментов.
Записан
Zmeishe
Гость
« Ответ #8 : Ноябрь 11, 2008, 13:55 »
Цитата: Константин от Ноябрь 11, 2008,  13:48
но я бы сделал чуть иначе: отдельным запросом можно найти необходимую строку, а из неё уже узнать родителя и уровень вложенности

Именно так и сделано.
Записан
ритт
Гость
« Ответ #9 : Ноябрь 11, 2008, 14:01 »
значит, не совсем правильно понял

может перенесёшь свою модель на склкверимодель и выложишь всем на радость? Улыбающийся
Записан
Zmeishe
Гость
« Ответ #10 : Ноябрь 11, 2008, 14:11 »
На склкверимодель точно не перенесу - я не работал с ней ни разу.
У меня своя QSocketModel наследник от QAbstractItemModel для работы по трёхзвенке, а на сервере приложений тоже склкверимодель не юзаю - там прямой API Interbase/Firebird заюзал.

Попробую, по возможности, сделать какую-нибудь выжимку.
Записан
ритт
Гость
« Ответ #11 : Ноябрь 11, 2008, 14:18 »
ну, хотя бы на QAbstractItemModel с использованием QSqlQuery в качестве источника данных? а там уже можно будет и под себя допилить при необходимости...
в любом случае, с нуля будет дольше и придётся сталкиваться с теми же проблемами, что другие уже победили в своих реализациях.
Записан
ритт
Гость
« Ответ #12 : Ноябрь 12, 2008, 09:44 »
мужики, совсем не в тему ведь! перенесите свои комменты в соответствующий тред, хорошо?
Записан
crossly
Гость
« Ответ #13 : Ноябрь 12, 2008, 09:59 »
мдя.... я так понимаю что никто так и не допилил.... лана придётся и дальше пользоватся поделками из standarditemmodel... по не найдется лишнего времени... Грустный
Записан
ритт
Гость
« Ответ #14 : Ноябрь 12, 2008, 10:21 »
лучше помоги пинать Zmeishe - я так понял, что у него часто случаются излишки свободного времени Улыбающийся
можно пива ему пообещать Подмигивающий
Записан
Страниц: [1] 2 3   Вверх
  Печать  
« предыдущая тема следующая тема »
 
Перейти в:  


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