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

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

Страниц: 1 [2]   Вниз
  Печать  
Автор Тема: QSqlQueryModel ,QAbstractItemModel  (Прочитано 16344 раз)
crossly
Гость
« Ответ #15 : Январь 13, 2010, 14:27 »

на практике.... если вы наследуетесь от QSqlQueryModel.... то соответственно и данные вам надо брать не из query а из data базового класса ... т.е. QSqlQueryModel::data....
Записан
paxerus
Гость
« Ответ #16 : Январь 13, 2010, 14:47 »

на практике.... если вы наследуетесь от QSqlQueryModel.... то соответственно и данные вам надо брать не из query а из data базового класса ... т.е. QSqlQueryModel::data....
да, я так и беру
Записан
MoPDoBoPoT
Гость
« Ответ #17 : Январь 13, 2010, 16:05 »

Я же писал, что парсить надо в методе setQuery (путем переопределения). После выбора данных делаем разбор, и запоминаем что надо (признак или еще что-то в нашу структуру, например, QList). А в методе data уже обрабатываем этот признак (подкрашиваем и т.п.)
Записан
crossly
Гость
« Ответ #18 : Январь 13, 2010, 16:30 »

Я же писал, что парсить надо в методе setQuery (путем переопределения). После выбора данных делаем разбор, и запоминаем что надо (признак или еще что-то в нашу структуру, например, QList). А в методе data уже обрабатываем этот признак (подкрашиваем и т.п.)
а если модель только для чтения... ??.... тем более что это все равно надо хранить в базе...
Записан
MoPDoBoPoT
Гость
« Ответ #19 : Январь 13, 2010, 16:35 »

а если модель только для чтения... ??
Ну, а в чем проблема? Я так и предполагал.
тем более что это все равно надо хранить в базе...
Где это сказано?
Записан
paxerus
Гость
« Ответ #20 : Январь 14, 2010, 07:25 »

В принципи предложенный метод меня вполне устраивает , в методе дата делаю разбор и возвращаю строку, но есть другой вопрос насколько быстро это будет происходить, тут ведь нужно постоянно RegExp делать при каждом выове Data,а если строк много например не будет ли тормозить?
В данном случае возможно setquery может быть лучше, я правильно понимаю что если делать через него то я смогу непросто подставлять данные а еще и сохраню их?
« Последнее редактирование: Январь 14, 2010, 07:33 от paxerus » Записан
crossly
Гость
« Ответ #21 : Январь 14, 2010, 14:03 »

а если модель только для чтения... ??
Ну, а в чем проблема? Я так и предполагал.
тем более что это все равно надо хранить в базе...
Где это сказано?
ну использование QSqlQueryModel предполагает использование БД...
Записан
paxerus
Гость
« Ответ #22 : Январь 14, 2010, 14:36 »

данные я не меняю в таблице, и вообще прямого изменения данных у меня нет, только через вызов процедур
Записан
MoPDoBoPoT
Гость
« Ответ #23 : Январь 14, 2010, 15:09 »

ну использование QSqlQueryModel предполагает использование БД...
Я, как бы, в курсе Улыбающийся Как я понял, предполагается читать данные из таблички БД и на стороне клиента как-то обработать/распарсить данные, выделив некую особенность, и указать на нее (цветом выделить или еще как-то). Исходя из этого я предложил разбор данных делать не каждый раз в методе data(), а один раз в методе setQuery() и закэшировать результат в какой-нибудь структуре (для признаков подойдет QBitArray). А в методе data() возпользоваться ранее полученными результатами разбора.
Например:
Код:
class CustomQueryModel : public QSqlQueryModel
{
Q_OBJECT
...
private:
conts int parseColumn; //номер столбца, в который надо разобрать
QBitArray *bitArray;       //массив признаков (наличие "ключа")
...
};
Код:
...
void CustomQueryModel::setQuery(const QSqlQuery & query)
{
QSqlQueryModel::setQuery(query);

//выбираем все данные, а то хз как их потом разобрать
while (myModel->canFetchMore())
    myModel->fetchMore();

parseData();   //<=в этом методе идет разбор данных
}

void CustomQueryModel::setQuery(const QString & query, const QSqlDatabase & db/* = QSqlDatabase()*/)
{
CustomQueryModel::setQuery(QSqlQuery(query, db));
}

void CustomQueryModel::parseData()
{
int count = rowCount();
QString strData;            //строка данных

//переинициализируем массив признаков
delete bitArray;
bitArray = new QBitArray(count, false);

for (int i = 0; i < count; ++i) {
strData = QSqlQueryModel::index(i, parseColumn).data().toString();
//далее идет проверка на наличие "ключа" и запись признака...
}
}

QVariant CustomQueryModel::data(const QModelIndex &index, int role) const
{
QVariant value = QSqlQueryModel::data(index, role);

//если "наш" столюец и роль= Qt::TextColorRole, то подкрашиваем текст
if (index.column() == parseColumn && role == ) {
if (bitArray->testBit(index.row())) {
return qVariantFromValue(QColor(Qt::green));
} else {
return qVariantFromValue(QColor(Qt::red));
}
}

return value;
}
...
НО возможно лучше будет денормализовать саму таблицу в БД, добавив еще одно поле - этот самый признак (чтобы каждый раз на каждом клиенте не делать разбор). Этот признак будет расчитываться в триггере на добавление/обновление записи в таблице БД.
« Последнее редактирование: Январь 14, 2010, 15:21 от MoPDoBoPoT » Записан
paxerus
Гость
« Ответ #24 : Январь 15, 2010, 11:33 »

ну использование QSqlQueryModel предполагает использование БД...
Я, как бы, в курсе Улыбающийся Как я понял, предполагается читать данные из таблички БД и на стороне клиента как-то обработать/распарсить данные, выделив некую особенность, и указать на нее (цветом выделить или еще как-то). Исходя из этого я предложил разбор данных делать не каждый раз в методе data(), а один раз в методе setQuery() и закэшировать результат в какой-нибудь структуре (для признаков подойдет QBitArray). А в методе data() возпользоваться ранее полученными результатами разбора.
Например:
Код:
class CustomQueryModel : public QSqlQueryModel
{
Q_OBJECT
...
private:
conts int parseColumn; //номер столбца, в который надо разобрать
QBitArray *bitArray;       //массив признаков (наличие "ключа")
...
};
Код:
...
void CustomQueryModel::setQuery(const QSqlQuery & query)
{
QSqlQueryModel::setQuery(query);

//выбираем все данные, а то хз как их потом разобрать
while (myModel->canFetchMore())
    myModel->fetchMore();

parseData();   //<=в этом методе идет разбор данных
}

void CustomQueryModel::setQuery(const QString & query, const QSqlDatabase & db/* = QSqlDatabase()*/)
{
CustomQueryModel::setQuery(QSqlQuery(query, db));
}

void CustomQueryModel::parseData()
{
int count = rowCount();
QString strData;            //строка данных

//переинициализируем массив признаков
delete bitArray;
bitArray = new QBitArray(count, false);

for (int i = 0; i < count; ++i) {
strData = QSqlQueryModel::index(i, parseColumn).data().toString();
//далее идет проверка на наличие "ключа" и запись признака...
}
}

QVariant CustomQueryModel::data(const QModelIndex &index, int role) const
{
QVariant value = QSqlQueryModel::data(index, role);

//если "наш" столюец и роль= Qt::TextColorRole, то подкрашиваем текст
if (index.column() == parseColumn && role == ) {
if (bitArray->testBit(index.row())) {
return qVariantFromValue(QColor(Qt::green));
} else {
return qVariantFromValue(QColor(Qt::red));
}
}

return value;
}
...
НО возможно лучше будет денормализовать саму таблицу в БД, добавив еще одно поле - этот самый признак (чтобы каждый раз на каждом клиенте не делать разбор). Этот признак будет расчитываться в триггере на добавление/обновление записи в таблице БД.
Спасибо ,вроде как данный метод самый целесообразный, денормализовать саму базу не могу, данные не мои и база от другой системы,в которую нельзя залезть
Записан
Страниц: 1 [2]   Вверх
  Печать  
 
Перейти в:  


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