Russian Qt Forum

Собственно задача

Допустим два пользователя просматривают данные большой таблицы. и один из них редактирует запись. после коммита, приложение второго получает уведомление от БД(Firebird), что в таблице X произошли изменения. Уведомление не может содержать идентификатора записи. Второму приложению надо бы обновить данные в модели, чтобы пользователь видел актуальную информацию.

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

Можно попробовать получить id измененной записи обходными путями и проапдейтить только ее в модели. Но, т.к. записи грузятся в кеш частями, записи может еще не быть в модели. А к тому моменту как второй пользователь до нее доползет, из базы выберется старая копия, т.к. бд версионная. fetchMore() тоже не выход т.к. таблица может оказаться большой.

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


Как вы обновляли данные в таких случаях? покажите свой велосипед  :)
если коротко - нужна логика когда и как обновлять модель

Реселектов модели конечно не избежать полностью, но можно попытаться сократить их количество. Может быть вы знаете как это все работает например в .net. Я нашел старую статью про BDE http://www.ibase.ru/devinfo/bde.htm (http://www.ibase.ru/devinfo/bde.htm), вроде как их живой кеш рефрешит данные которые в данный момент на экране.

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

Правда, штатным драйвером Qt тип транзакции выбрать нельзя.

ну можно двигаться назад по таблице и надо когда то рефрешить всю модель

Я не смотрел исходник модели, но сомневаюсь, что она всё хранит, что прочитала из БД, ведь таблица может быть гигантской.

вроде бы у модели есть QSqlResult с помощью которого она гуляет по записям, а дальше уже зависит от драйвера

А что за уведомления в сервере что-то новое появилось или вы сами реализовали их? Много работал с FB и ничем таким не пользовался...

Вы точно уверены что вам эту задачу решать надо? - скажем если бы речь шла о чеке или накладной - то чтобы 2 продавца не продали бы 1 последнюю позицию товара - я бы перед коммитом накладной в отдельной транзакции сверял еще раз количество в накладной с наличием на складе, с соответствующими выводами.

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

Вот про уведомления http://labs.trolltech.com/blogs/2007/11/02/asynchronous-database-event-notifications/ (http://labs.trolltech.com/blogs/2007/11/02/asynchronous-database-event-notifications/)


нет, не уверен :)
поэтому и спрашиваю кто каким велосипедом пользуется
например, "не часто" это с каким интервалом и после каких событий?

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

да


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

похожую идею я в самом начале описал:

"Можно делать селект только идентификаторов и подгружать те записи из БД которые в данный момент на экране. Количество обращений к базе растет, но выборка идет по первичному ключу, т.е. оч. быстро. Не очень понятно стоит ли выносить выборку нужных записей в отдельный поток или нет. Если да - то встает вопрос синхронизации при частых дерганиях скроллбара."

поедет ли этот велосипед?

Поедет наверное но я бы так делать не стал - не очень как то надежно... Если пользователь будет бегать по записям и они сами будут меняться - не будет ли это неудобно для него?

зато потом можно беспроблемно прикрутить сфинкс для полнотекстового поиска ;)