QSqlQueryModel и нормальный refresh

[GreatSnake]

1. собственно обновление изменившихся данных (новые/удаленные/изменившиеся строки) - это собственно сделано;

Есть подозрение, что если нормально обновлять модель (испускать соответствующие сигналы), то вью сама должна нормально позиционировать текущий элемент и вьюпорт.

[xokc]

если нормально обновлять модель (испускать соответствующие сигналы), то вью сама должна нормально позиционировать текущий элемент и вьюпорт.

И ещё раз: есть 2 разных компа с моими приложениями. На PC1 пользователь удалил запись, которая является в этот момент текущей во вью на PC2. Кто, кому и какой должен испустить сигнал, чтобы при обновлении вью на PC2 текущей стала "ожидаемая строка"?

[Old]

И ещё раз: есть 2 разных компа с моими приложениями. На PC1 пользователь удалил запись, которая является в этот момент текущей во вью на PC2. Кто, кому и какой должен испустить сигнал, чтобы при обновлении вью на PC2 текущей стала "ожидаемая строка"?

У меня база посылает уведомление о изменении таблицы (добавление/изменение/удаление записи) и все модели на всех рабочих местах добавляют/перечитывают/удаляют нужную строку.
База postgresql.

[GreatSnake]

И ещё раз: есть 2 разных компа с моими приложениями. На PC1 пользователь удалил запись, которая является в этот момент текущей во вью на PC2. Кто, кому и какой должен испустить сигнал, чтобы при обновлении вью на PC2 текущей стала "ожидаемая строка"?

Каким образом обновляется модель на PC2?

[Hellraiser]

У меня база посылает уведомление о изменении таблицы (добавление/изменение/удаление записи) и все модели на всех рабочих местах добавляют/перечитывают/удаляют нужную строку.
База postgresql.

Таковым механизмом обладают далеко не все СУБД. В таком случае - либо кнопка рефреша, либо костыль с таймером.
У меня при выборе СУБД для проекта наличие механизма нотификации дало серьезное преимущество для Постгре.

[xokc]

Каким образом обновляется модель на PC2?

По нажатию кнопки "Refresh".

У меня база посылает уведомление о изменении таблицы.

Уходим в сторону от изначального вопроса, который заключался не в этом, а в том, как "ожидаемо" спозиционироваться на строку после рефреша, если предыдущая текущая запись была удалена. Плюс мне такой подход с автоматическим обновлением по уведомлению об изменении не подойдет: изменения происходят слишком часто - в этом режиме работать с таблицей будет невозможно. Кстати, как узнаёте, что инициатором изменения была текущая модель, и, следовательно, специально обновляться не надо?

[GreatSnake]

Таковым механизмом обладают далеко не все СУБД. В таком случае - либо кнопка рефреша, либо костыль с таймером.

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

[GreatSnake]

По нажатию кнопки "Refresh".

Ну что за ответ
Тебе хотят помочь, а ты кривляешься. Как-то даже не серьёзно. 

[xokc]

По нажатию кнопки "Refresh".

Ну что за ответ
Тебе хотят помочь, а ты кривляешься. Как-то даже не серьёзно. 

Ну какой вопрос, такой и ответ . Ничуть не кривлялся. Если вопрос был о механизме обновления, а не о его инициаторе (а я его понял именно так ), то - так, как это сделано в примере из состава Qt (examples\sql\querymodel\editablesqlmodel.cpp), а именно:

Код

C++ (Qt)
void EditableSqlModel::refresh()
{
    setQuery("select ...");
}

Тебе хотят помочь

От помощи не откажусь и буду благодарен - для того и вопрос задавал.

[GreatSnake]

Получается, что модель при обновлении полностью чистится. Поэтому вью тоже сбрасывается.
Тут есть 2 решения, либо написать свою модель с нормальным рефрешем либо держать 2 QSqlQueryModel-и.
Первая основная, а вторая временная для валидации первой.

[Old]

Кстати, как узнаёте, что инициатором изменения была текущая модель, и, следовательно, специально обновляться не надо?

У меня все действия с таблицей можно выполнять только через методы модели, поэтому внутримодельного флага достаточно.
Я не использую Qt-модели для работы с базами, сразу написал свои со всякими "плюшками".

[Old]

Получается, что модель при обновлении полностью чистится. Поэтому вью тоже сбрасывается.
Тут есть 2 решения, либо написать свою модель с нормальным рефрешем либо держать 2 QSqlQueryModel-и.
Первая основная, а вторая временная для валидации первой.

Достаточно хранить список с уникальными id записей. Перед рефрешем заполняем его, после смотрим что изменилось.

[GreatSnake]

Достаточно хранить список с уникальными id записей. Перед рефрешем заполняем его, после смотрим что изменилось.

Да, так будет ещё оптимальнее.

[xokc]

Спасибо за ответы, вижу, что простого решения нет - жаль. Ну и пользуясь случаем: у меня в модели есть "вычисляемое" поле, то есть то поле, которого нет в БД (значение из модели отдается через model::data()). Как мне при его изменении (не средствами View) наиболее правильно оповестить View о том, что надо бы это значение перерисовать без полного refresh (как сделано в примере editablemodel) модели?

[GreatSnake]

Код

C++ (Qt)
QTableVeiw::viewport()->update();
QTableVeiw::viewport()->update( QTableVeiw::visualRect( index ) );