balu
Смысл в таком обновлении?

Предположим, что есть некая таблица со списком свободных на данный момент машин.
Оператор выбирает из этого списка машину и отправляет ее по маршруту. Естественно машина из категории свободных переходит в категорию занятых. Все пока удачно складывается. Но в это же самое время или чуть по позже оператор на другой локальной станции выбирает эту же самую машину(данные грида у него не изменились и машина числиться в числе свободных) и отправляет ее по другому маршруту. Вопрос: Что делать водителю? И по какому маршруту он пошлет операторов и прогу?
Вот для того чтобы лишних вопросов не возникало и нужно динамическое обновление всех гридов после изменений в бд.
Пример из головы. На самом деле может быть все намного серьезнее.

2 Smar. Выхода 2. Либо перечитывать данные по таймеру. Самая простая реализация, но имеет следующие минусы:
1) важно решить как часто надо обновлять данные, чтобы и не загружать железо и обновлять почаще.
2) в периоды между обновлениями данные могут устареть
3) велика вероятность возникновения ситуации, когда ты перечитываешь данные и заносишь их в таблицу, а в это время уже данные изменились. Либо ты делаешь операцию над записью, и в это время начинается обновление по таймеру - тут надо делать блокировку таймера, а это чревато конфликтом внесенных данных.
Реализация посложней. 1 раз загрузить в таблицу, а при операции над записью перечитывать данные для конкретной записи, обновляя и строку в таблице, и данные в форме заполнения. Если данные не подходят пользователь получает отлуп. Также желательно делать аналогичную проверку во время операции модификаци уже на уровне СУБД.

Smar

balu
Смысл в таком обновлении?

Предположим, что есть некая таблица со списком свободных на данный момент машин.
Оператор выбирает из этого списка машину и отправляет ее по маршруту. Естественно машина из категории свободных переходит в категорию занятых. Все пока удачно складывается. Но в это же самое время или чуть по позже оператор на другой локальной станции выбирает эту же самую машину(данные грида у него не изменились и машина числиться в числе свободных) и отправляет ее по другому маршруту. Вопрос: Что делать водителю? И по какому маршруту он пошлет операторов и прогу?
Вот для того чтобы лишних вопросов не возникало и нужно динамическое обновление всех гридов после изменений в бд.
Пример из головы. На самом деле может быть все намного серьезнее.

Не, ну с таких позиций… нужно архитектуру и ui планировать для разруливания таких ситуаций. Грид, IMHO, не самое лучшее решение.

Та же самая модель с машинами, но, допустим, ты сделал, что в гриде статус машины push-ится всем пользователям. Пользователь видит - машина свободна, начинает отправлять ее по маршруту. Пока вводит данные о маршруте, другой диспетчер эту же машину успевает отправить по другому маршруту. Статус в гриде поменяется, но диспетчер этого уже не увидит.

Я просто к тому, что за-push-ивание данных в грид не спасет. Нужно думать о блокировках. Т.е. если диспетчер открыл запись на редактирование, то другие это сделать не могут.

j2a
Та же самая модель с машинами, но, допустим, ты сделал, что в гриде статус машины push-ится всем пользователям. Пользователь видит - машина свободна, начинает отправлять ее по маршруту. Пока вводит данные о маршруте, другой диспетчер эту же машину успевает отправить по другому маршруту. Статус в гриде поменяется, но диспетчер этого уже не увидит.

Я просто к тому, что за-push-ивание данных в грид не спасет. Нужно думать о блокировках. Т.е. если диспетчер открыл запись на редактирование, то другие это сделать не могут.

Вернемся к модели:
При выборе свободной машины оператор автоматически переводит ее в разряд занятых.
Технически организовать это не сложно. Предположим в таблице есть поле “Выбор” имеющее значения True\False. Выборка в грид идет по условию False. При выборе машины поле принимает значение True, что противоречит условию. Соответственно машина должна автоматом исчезнуть из грида. Ничто не мешает ей туда вернуться в случае отмены выбора. Вот эти изменения и должны дойти до всех локальных станций. Тогда необходимость что либо блокировать на данном этапе пропадает.

j2a
Грид, IMHO, не самое лучшее решение.

В wxPython при реализации MVC модели с бд используется PyGridTableBase. Напрямую этот класс не связан с гридом, но имеет все те же недостатки, что и собственно грид(см. выше). Увы, но это так. Но если честно я не знаю другого инструмента в wx.

Smar

j2a
Та же самая модель с машинами, но, допустим, ты сделал, что в гриде статус машины push-ится всем пользователям. Пользователь видит - машина свободна, начинает отправлять ее по маршруту. Пока вводит данные о маршруте, другой диспетчер эту же машину успевает отправить по другому маршруту. Статус в гриде поменяется, но диспетчер этого уже не увидит.

Я просто к тому, что за-push-ивание данных в грид не спасет. Нужно думать о блокировках. Т.е. если диспетчер открыл запись на редактирование, то другие это сделать не могут.

Вернемся к модели:
При выборе свободной машины оператор автоматически переводит ее в разряд занятых.
Технически организовать это не сложно. Предположим в таблице есть поле “Выбор” имеющее значения True\False. Выборка в грид идет по условию False. При выборе машины поле принимает значение True, что противоречит условию. Соответственно машина должна автоматом исчезнуть из грида. Ничто не мешает ей туда вернуться в случае отмены выбора. Вот эти изменения и должны дойти до всех локальных станций. Тогда необходимость что либо блокировать на данном этапе пропадает.

Те же яйца, только в профиль.

Smar

j2a
Грид, IMHO, не самое лучшее решение.

В wxPython при реализации MVC модели с бд используется PyGridTableBase. Напрямую этот класс не связан с гридом, но имеет все те же недостатки, что и собственно грид(см. выше). Увы, но это так. Но если честно я не знаю другого инструмента в wx.

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

P.S. http://www.artlebedev.ru/everything/roentgenprom/proscan/scenarios/

j2a
Я к тому, чтобы вообще пересмотреть ui. Так ли необходимо оператору постоянно видеть список свободных машин? Возможно, он нужен только тогда, когда она добавляет новую заявку? Возможно, есть смысл использовать другой контрол, не грид? Тут необходим анализ сценариев работы.

Согласен, путей обхода этой проблемы не много, их очень много.
Дело не в конкретной модели. В конце концов это всего лишь модель.
Обойти проблему-не значит ее решить. Как показывает практика не решенная проблема в конце концов вернется, при чем в самый неподходящий момент. Я пытаюсь понять можно ли вообще это решить, а не как это обойти.

Smar

j2a
Я к тому, чтобы вообще пересмотреть ui. Так ли необходимо оператору постоянно видеть список свободных машин? Возможно, он нужен только тогда, когда она добавляет новую заявку? Возможно, есть смысл использовать другой контрол, не грид? Тут необходим анализ сценариев работы.

Согласен, путей обхода этой проблемы не много, их очень много.
Дело не в конкретной модели. В конце концов это всего лишь модель.
Обойти проблему-не значит ее решить. Как показывает практика не решенная проблема в конце концов вернется, при чем в самый неподходящий момент. Я пытаюсь понять можно ли вообще это решить, а не как это обойти.

Нет. Это проблема при текущем подходе. Я редко встречал ситуации, когда pushable grid был бы акутален (плюс, он еще очень плохо масштабируется). Чаще всего, это ошибки в проектировании системы/ui. Я не говорю, что у тебя эта ситуация. Но программисту чаще легче сделать pushable grid, чем пересмотреть и проанализировать сценарии работы.

Согласен, легче. Но почему-то легче не стало. :)

Smar
Согласен, легче. Но почему-то легче не стало.

Чем не подходит предложенный мной вариант?

balu
Smar написал:

Согласен, легче. Но почему-то легче не стало.

Чем не подходит предложенный мной вариант?

По первому варианту:
Он конечно простой, рабочий на 100%. Но …
Нагрузка на бд, память и все что с этим связано будет возрастать в геометрической прогресии с подключением каждой новой станции. И не очень надежен к тому же.
В принципе подойдет для небольших сетей с не очень нагруженными во временном промежутке изменениями.
Как альтернативу таймеру могу предложить такой вариант (тоже далеко не лучший):
При включении “Сервера” создается вспомогательная бд в которую наряду с изменениями в основной бд грид вписывает строку типа где,что и как изменил . При изменении в этой таблице (ловится на ID или по количеству строк(кому как нравится)) станции считывают последнюю строчку и сами решают что же с этим добром делать. Так достигается независимость от промежутка времени. Гриду не надо перебирать весь набор данных, на постоянной основе сравнивается лишь одно число.
При выключении сервера дополнительная бд гробится.
Этот метод имеет схожие с таймером недостатки по нагрузке системы и по тому может использоваться на не больших сетях.

Мне все же нравится идея использования socket.

По второму способу надо еще думать.