QSqlRelation и фильтр

[hamlo]

Собсвенно

Код:

actTableView = new QTableView(this);
model = new QSqlRelationalTableModel;
model->setEditStrategy(QSqlTableModel::OnManualSubmit);
model->setTable("mediko_economic_certificate");
model->setFilter("act_id = "+QVariant(++*actId).toString()+" AND is_deleted=0");
model->select();
model->setRelation(14, QSqlRelation("infringement_main_point_list","infrigement_point","infrigement_point"));
actTableView->setModel(model);
actTableView->setSelectionBehavior(QAbstractItemView::SelectRows);
actTableView->show();
actTableView->setItemDelegate(new QSqlRelationalDelegate(actTableView));

1. Вопрос - почему порядок, указанный в документации сначала setRelation() а  затем select() - НЕ работает(по крайней мере в этом случае, возможно я что то упускаю), так же как и порядок из доки setItemDelegate() а затем show().

2. Основной вопрос: в таблице  infringement_main_point_list надо выбирать не все записи в выпадающий список, а только те, у которых is_deleted=0. Напрашивается вопрос: есть ли для QSqlRelation какое либо окольное решение, которое бы давало эффект setFilter() для основной модели.

[break]

1) вообще то для QSqlRelationTableModel так и указано - сначало setTable() - кот. откроет модель, затем setRelation - код из ассистента

The following code snippet shows how the QSqlRelationalTableModel was set up:

     model->setTable("employee");

     model->setRelation(2, QSqlRelation("city", "id", "name"));
     model->setRelation(3, QSqlRelation("country", "id", "name"));

вторую часть вопроса я не понял - зачем там show - таблица что не вставлена нив какое родительское окошко?

2) вохоже что в QSqlRelation действительно нет возможности задать фильтр - простейший способ выхода из ситуации написать своего делегата кот. будет и отображать данные верно и позволять редактировать давая отсеивая только нужные. Можете написать продвинутый QSqlRelationDelegate с возможностью задать фильтры на все случаи жизни для табличек. Тогда может удасться обойтись там вообще без setRelation...

[Marat(Qt)]

По поводу фильтра:
для этого делают представление с выборкой и задают relation для нее а не для оригинальной таблицы

[hamlo]

Отказался от Relation. Написал свою фукцию, которая обрабатывает значение одного поля и устанавливая его значение как ключ - выбираются значения из нужной таблицы. Сейчас времени нет - но собсвенная реализация делегата - необходима, чем и займусь попозже - сейчас важен результат.

ЗЫ За дефолтное отсутствие параметра фильтров у relation  - Qt - как библиотеке огромный минус. Ещё минус - за некорректную работе removeColumn(idx) у моделей. Не сдвигает указатели на столбец - это официальный баг. Вообщеем работать и работать TrollTech у ещё над фреймворком..

[break]

для этого делают представление с выборкой и задают relation для нее а не для оригинальной таблицы

Чё?
К вьюхе что-то чтоли хотите прикрутить? Если же вы имеете ввиду View - ы которые есть в некоторых БД то увы чаще всего они READONLY

[Marat(Qt)]

View конечно readonly, никто их содержимое менять не собирается, надо просто с помощью qsqlrelation сделать подстановку из view, при этом при изменении поля будет меняться не содержимое view, а содержимое таблицы, в которую производится подстановка. Если view содержит не все строки, например нет строки номер 5, то все строки исходной таблицы, требующие 5-тую строку для подстановки просто спрячутся, т.е. отфильтруются, как этого хотел топикстартер

К вьюхе что-то чтоли хотите прикрутить?

Естесственно речь идет о View из БД

[break]

надо просто с помощью qsqlrelation сделать подстановку из view,

Может это окажется решением но далеко не во всех случаях(я даже считаю что это костыль - правильное решение это вставка необходимого текста  select * from .... в QSqlRelation - жаль этой ф-сти нет там) - если например есть таблица с колонками

ГРУППА \ УЧЕНИК

и от поля группа - должны зависеть возможные списки значений таблицы ученик - делать все возможные варианты VIEW - неправильно, а если выбирать уже из VIEW - то почему не выбирать из самой таблицы...

[Marat(Qt)]

делать все возможные варианты VIEW - неправильно

view - не так уж и сложно сделать, по сути это запрос на выборку, имеющий свое имя.
Ну допустим создали вы view с именем view1 - воспользовались, нужен другой view, в старом необходимость отпала, пожалуйста, создали новый view поверх старого - снова view1 - воспользовались... Не думаю что это будет нагружать БД, ибо view ничуть не сложнее запроса. А вот то что данные фильтруются на стороне сервера - это хорошо, меньше данных перекидывать.

если выбирать уже из VIEW - то почему не выбирать из самой таблицы...

из view никто не выбирает, он берется целиком, так как все выборки уже в нем

я даже считаю что это костыль

а я считаю, что то, чего вы хотите - велосипед, ибо все уже в субд имеется

[break]

view - не так уж и сложно сделать, по сути это запрос на выборку

Да вы похоже не понимаете о чем говорите я работаю с БД firebird - там View деалется как таблица и деалть его в коде каждый раз когда нужно совершенное неудобно, параметризированных VIEW не бывает - да это идиотизм т.к. проще сделать отдельный запрос

Не думаю что это будет нагружать БД, ибо view ничуть не сложнее запроса. А вот то что данные фильтруются на стороне сервера - это хорошо, меньше данных перекидывать.

В коде - в коде - в коде представь создание вьева, использование, удаление - create VIEW /...,,,,,,,, drop VIEW и т.д. нах это нужно? кроме того где я по твоему предложил фильтровать данные на клиенте??? в улучшенный QSqlRelation  или в своем делегате надо выполнять запрос с параметром для возврата необходимого списка значений комбобокса - и в обоих случаях данные ( не подходящие записи) фильтруются на сервере!!!

из view никто не выбирает, он берется целиком, так как все выборки уже в нем

я не знаю с какой вы БД работаете - но в FB вьев это фактически однократная выборка - то есть запрос - может с джойном, может с использованием сложной хранимой процедуры - и это SQL код - сам по себе в БД он данных не содержит!!! а когда я работаю с VIEW я делаю так как будто выбираю из таблицы

select *
from MY_VIEW

и тут уже идет выборка из VIEW - так что сори за язык но "не парь мне мозг" ты в тематике плаваешь!!!

а я считаю, что то, чего вы хотите - велосипед, ибо все уже в субд имеется

а вот с этого момента поподробнее т.к. то что описал я это и есть то что имеется в СУБД а вы хотите катамаран со своими VIEW-ами

[Marat(Qt)]

К чему такие эмоции?

Код:

query.exec("CREATE OR REPLACE VIEW имя_представления AS запрос");

Это правда похоже на катамаран? тебе так сложно написать свой запрос после AS а не в делегате или где либо еще? назначение запросу имени - зверски снижает производительность? в честь чего?

[break]

Я и слова не сказал про производительность - а вот то что это делать(создавать VIEW) в коде для создания списка возможных значений комбобокса НЕУДОБНО - это очевидно - т.к. каждый раз мы создаем VIEW - потом его надо удалять, следить чтобы он не остался в БД в качестве хлама и т.д. зачем это? какую роль играет VIEW если на этом же месте можно сделать запрос? И все же я не получил ответа на остальные вопросы...

[Marat(Qt)]

и деалть его в коде каждый раз когда нужно совершенное неудобно

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

удаление - create VIEW /...,,,,,,,, drop VIEW и т.д. нах это нужно?

правильное решение это вставка необходимого текста  select * from .... в QSqlRelation

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

[break]

Не знаю что у вас там бузвыходно у меня эта ситуация работает со своим делегатом комбобокса без всяких городушек с вьюв.

[Marat(Qt)]

у меня эта ситуация работает со своим представлением без всяких городушек с делегатами

[break]

А если значения выпадающего списка должны зависеть от соседних полей, кот. пользователь может поменять? - будете создавать новые ВЬЕВы снова и снова? То есть плодить метаданные сомнительной необходимости в БД?